What Is CDN? How Edge Delivery Actually Works

A content delivery network is a geographically distributed group of servers that stores or relays internet content closer to website visitors. Put another way, it is a globally distributed network of servers that delivers web content while reducing physical distance and keeping user requests away from the origin server when cached material is available.

The useful part of the CDN meaning is not simply "servers around the world." The delivery network sits in the request path. DNS, anycast routing or both direct a visitor toward a nearby CDN location, usually called a point of presence. An edge server there checks whether it already holds a reusable response.

A **cache hit** lets the edge return that response without contacting the website's hosting server. A **cache miss** makes the edge request the object from the origin, return it to the visitor and, if policy permits, cache content for later requests. HTTP caching decisions depend on headers including Cache-Control, Age, ETag and Vary, as specified by the HTTP caching standard↗.

That distinction matters. A CDN does not automatically copy an entire website to every city, and it does not make every response cacheable. Public images, style sheets, JavaScript bundles, fonts and video segments are straightforward candidates. Shopping carts, account pages and personalized HTML commonly bypass the cache unless the operator has designed explicit cache keys and rules for them.

The cache key determines whether two requests can share one stored response. It normally includes the host and URL, but may also include selected query parameters, headers or cookies. An overly broad key can deliver one user's personalized response to another visitor. An overly narrow key destroys the hit ratio and raises bandwidth consumption.

A CDN can also enhance security because traffic reaches its network before it reaches the origin. Rate controls, firewall rules and DDoS mitigation can discard some malicious requests at the edge. That protection fails if attackers can discover and contact an unrestricted origin IP directly.

CDN architecture puts a control layer and distributed cache layer between a site's authoritative origin and its visitors. A request reaches an edge location, where it is served from cache or forwarded upstream on a miss.

The request path is concrete:

1. The site points a hostname at the CDN through DNS.
2. The visitor resolves that name to an address announced by the CDN.
3. Internet routing carries the connection to an available edge location.
4. The edge terminates TLS and evaluates security and cache rules.
5. A hit returns stored content. A miss triggers an upstream request.
6. The origin generates the response, which the edge may store before delivery.

“Nearest” is shorthand. Routing can account for peering, congestion, capacity and outages rather than physical distance. Anycast allows multiple locations to advertise reachability for the same IP address, while internet routing selects an available path, as described in the IETF's Anycast deployment guidance↗.

The control layer distributes TLS certificates, redirects, cache rules, firewall policy and origin definitions. The data layer handles user requests and cached objects. This separation lets a configuration change propagate without rebuilding every stored file, although propagation is not instantaneous.

Larger networks may use tiered storage. An edge cache asks a regional parent cache for an object before contacting the origin. This reduces bandwidth consumption, but adds another place where stale content can survive.

Freshness determines how long a response may be reused. Cache-Control: max-age=300 allows a shared cache to treat it as fresh for five minutes, subject to other directives. An ETag lets an expired object be validated with a small 304 Not Modified response. MDN documents these shared-cache mechanisms↗.

Purging is an escape hatch. A global invalidation takes time, so overwriting app.js can leave mismatched HTML and JavaScript at different edges. Content-hashed names such as app.4f91c2.js avoid that race because each release receives a new cache key.

Origin shielding and request collapsing reduce upstream work. A shield funnels misses through one cache tier. Collapsing lets one upstream fetch satisfy many simultaneous misses, preventing an expired popular object from producing a thundering herd at the origin.

A CDN usually handles an edge failure by routing new connections to another location, but it cannot guarantee that a website remains available. The origin, DNS, TLS configuration, cache policy and CDN control plane remain separate failure points.

The common operational surprise is stale content. Long freshness lifetimes improve website performance and reduce bandwidth, but they also preserve mistakes. Purging the wrong URL, overlooking a query string or omitting a response-changing header from the cache key can leave visitors receiving different releases.

Do not mistake edge capacity for origin capacity. Cached files may account for most transferred bytes while uncached HTML and API calls create most computing work. During a traffic spike, images can remain fast while checkout requests overload the application database. Inspect hit ratio by content type and origin request volume, not merely total edge delivery.

Failures expose dependency order:

• Broken authoritative DNS prevents visitors from finding the CDN.
• An expired edge certificate stops HTTPS before cache lookup.
• A blocked origin address makes misses fail while old cached objects may still work.
• A redirect loop can appear when the edge uses HTTPS but its origin connection uses HTTP.
• A broad cache rule can store private HTML or error pages.
• A routing fault can increase latency while every server reports healthy.

Some providers support stale-if-error behavior, serving expired cached material when the origin fails. That can preserve accessible articles and images during an outage, but it is a poor fit for prices, authentication state or changing account data. Resilience depends on deciding which content may safely be old.

A CDN can boost performance for visitors far from the origin, large static files, repeat requests or sudden bursts. It is harder to justify for a private dashboard used by five people in one office. The additional DNS, TLS termination and cache configuration should buy a measurable improvement.