Content Delivery Networks

A content delivery network (CDN) is a geographically distributed set of servers, called edge servers or points of presence (PoPs), that cache and serve content on behalf of an origin server. A user's request is routed to a nearby edge. If the edge has the content it responds directly. Otherwise, it fetches from the origin, stores the response, and returns it.

Problems a CDN solves

• Latency: a request to a distant origin pays many round trips (TCP and TLS setup, then the request). Physical distance sets a floor: light in fiber travels about 200,000 km/s, so a round trip across an ocean takes on the order of tens to 100+ milliseconds. An edge near the user shortens every round trip.
• Origin load: most requests for popular content are served from edge caches, so the origin sees a fraction of the traffic. At 10,000 requests per second and a 95% cache hit ratio, the origin receives 500 requests per second.
• Bandwidth cost and capacity: large static objects (images, video segments, downloads) are delivered from the edge.
• Availability and traffic spikes: a CDN absorbs flash crowds and, with stale-if-error behavior, can serve cached content when the origin is down.
• Security: CDNs terminate TLS at the edge and absorb volumetric DDoS attacks using their large aggregate capacity. Many offer a web application firewall.

How requests reach the edge

• DNS-based routing: the CDN's authoritative DNS returns the address of a suitable edge based on the resolver's location or measured latency and load (see DNS resolution). The site's hostname is typically a CNAME to a CDN hostname.
• Anycast: many edges announce the same IP address, and network routing delivers each client to a topologically near one.
• Many CDNs combine both.

flowchart LR
    U["User"] --> E["Nearby edge server"]
    E -->|"cache hit"| U
    E -->|"cache miss"| S["Regional cache or origin shield"]
    S -->|"miss"| O["Origin server"]
    O --> S
    S --> E

Pull versus push CDN

Pull is the default model for most web content.

What the edge caches: cache keys

The cache key identifies a cached object. By default it consists of the host and the full URL including the query string. Rules decide what is part of the key:

• Different query strings create separate entries: /img/a.jpg?utm_source=x and /img/a.jpg?utm_source=y are cached twice unless the tracking parameter is excluded from the key. Ignoring irrelevant parameters (tracking parameters) or sorting parameters increases the hit ratio.
• Headers listed in the response Vary header (for example Accept-Encoding) extend the key. Varying on Cookie or User-Agent fragments the cache and lowers hits.
• Device type, language, or country can be added deliberately.

A key that is too specific causes low hit ratios. A key that is too coarse can serve the wrong variant, for example a personalized page to another user. Responses containing user-specific data should not be cached at shared edges (Cache-Control: private).

TTL and cache control

The origin controls caching with HTTP headers (see REST API design):

• Cache-Control: max-age=<s> sets freshness for browsers and shared caches. s-maxage sets a value for shared caches such as CDNs only.
• Cache-Control: no-store prevents caching. private prevents shared caches from storing.
• Cache-Control: stale-while-revalidate=<s> allows serving a stale copy while a background refresh happens, and stale-if-error allows stale content when the origin fails.
• Validators (ETag, Last-Modified) let the edge revalidate with a conditional request and receive 304 Not Modified cheaply.

CDNs can also override TTLs with their own rules. Choose the TTL per content type: long for immutable assets, short for content that changes often.

Invalidation and versioning

Content sometimes changes before its TTL expires. Options:

• Purge (invalidation): instruct the CDN to remove an object, a path pattern, or objects with a given tag or surrogate key. Purging must reach every edge, so its propagation time depends on the provider, and some providers limit or charge for purge volume.
• Versioned (fingerprinted) URLs: include a content hash or version in the file name (app.3f9a1c.js), so a change produces a new URL. Old and new versions coexist, and the old one expires naturally. This lets assets be cached with a very long TTL (for example a year, with immutable) and requires no purge. The HTML referencing them uses a short TTL or must be revalidated.
• Short TTL for content that tolerates brief staleness.
• Soft purge: mark content stale but serve it while revalidating.

Versioned URLs are the most reliable approach for static assets, and purging by tag suits dynamic content such as product pages.

Origin shield and tiered caching

Each edge caches independently. If a popular object expires or is requested for the first time, many edges can all miss and hit the origin at once. With 50 edges, one new object can cause 50 origin requests.

An origin shield (or tiered cache) is an intermediate caching layer between edges and origin. Edges that miss ask the shield; only the shield goes to the origin on a miss. Effects:

• Fewer origin requests, since misses from many edges collapse into one (50 origin requests become 1 in the example above).
• Higher overall cache hit ratio for the origin.
• One additional hop on a miss.

Request coalescing (collapsed forwarding) at the edge and shield lets concurrent requests for the same uncached object wait for one origin fetch instead of each going through. This is the same defense as in cache invalidation, stampede, and hot keys.

Dynamic content and other features

• Dynamic content acceleration: uncacheable requests still benefit from the edge terminating the client connection close to the user and reusing warm, optimized connections to the origin.
• Edge compute: code runs at the edge for redirects, header logic, authentication checks, and A/B routing.
• Streaming video is delivered as short segments (HLS, DASH), each a cacheable object, which suits CDN caching.
• Large file downloads use range requests, so the edge can cache and serve parts.
• Protocol support: edges typically speak HTTP/2 and HTTP/3 to clients regardless of the origin's protocol (see HTTP/1.1, HTTP/2, and HTTP/3).

When to use and when not to

Use a CDN for:

• Static assets (JavaScript, CSS, images, fonts) of any site with a geographically spread audience.
• Video and large media delivery.
• Public, cacheable API responses with tolerance for slight staleness.
• Protection against traffic spikes and DDoS attacks.

Weak fit:

• Highly personalized or real-time responses that cannot be cached, where only connection-level acceleration helps.
• Users concentrated in one region close to the origin.
• Content with strict freshness or access-control requirements, unless using signed URLs or tokens: a private object served at the edge needs signed URLs or cookies with expiry so that only authorized users obtain it.

Costs and risks: egress and request pricing, cache misconfiguration (wrong keys leak or fragment content), stale content after failed purges, and dependence on a third-party provider.

Interview questions

• How does a CDN decide whether to serve from cache? It computes the cache key, checks for a fresh entry using the TTL from Cache-Control, and serves it on a hit. On a miss or expired entry, it fetches or revalidates with the origin.
• Why use versioned file names instead of purging? A new name is a new cache key, so it is used immediately everywhere, and old versions can keep a long TTL. Purges are asynchronous across edges and can be rate-limited.
• What does an origin shield do? It adds a central cache layer so that misses from many edges become one request to the origin, which reduces origin load and raises the hit ratio.
• How can private content be served through a CDN? Use signed, expiring URLs or cookies validated at the edge, and mark user-specific responses as not cacheable by shared caches.