Content Delivery Networks

A content delivery network, or CDN, delivers content through distributed infrastructure. Instead of sending every request to one origin server, a CDN routes a request to an edge location that can serve it.

The edge location may already hold a reusable response. That is a cache hit. The edge returns the response without asking the origin. If no usable response exists, a cache miss occurs. The CDN fetches from the origin or another cache layer, forwards the response, and may store it for later requests.

This design can reduce latency, network traffic, and origin load. It also creates distributed state. You must decide what can be cached, how long it stays fresh, which request details create distinct variants, and how updates replace old content.

The request path

A typical request follows this path:

1. A user agent resolves the application hostname.
2. Request routing selects a suitable edge location.
3. The edge builds a cache key from the request.
4. The edge looks for a stored response under that key.
5. A hit returns from the edge.
6. A miss travels toward the origin, possibly through an upper-tier cache.
7. The response returns to the user and may populate caches along the path.

The selected edge is not always the geographically nearest site. A provider can consider network latency, reachability, capacity, and policy. The practical goal is a suitable delivery point, not a dot that looks closest on a map.

The origin remains the authoritative source for the content. An origin can be a web server, object store, application service, or another delivery system. The CDN sits between user agents and that origin. It does not remove the need to operate the origin correctly.

A CDN is more than a cache

Caching is central, but a CDN also needs request routing, distribution, control, and logging functions. Those functions answer different questions.

• Request routing: Which edge should receive this request?
• Delivery: How does the edge return content to the user agent?
• Distribution: How does content or metadata reach edge locations?
• Control: Which delivery rules and configurations apply?
• Logging: What happened during delivery?

Some content is acquired on demand after a miss. This is often called pull delivery. Other content can be placed before demand arrives. Many services also use cache hierarchies. A lower-tier edge asks an upper tier before it asks the origin. That can reduce duplicate origin fetches across many edge locations.

The cache key controls correctness and reuse

A cache key identifies a stored response. HTTP requires at least the request method and target URI to participate. CDN products can also include query strings, headers, cookies, and normalized request attributes.

Include a request value when it changes the representation returned by the origin. For example, a language header belongs in the key when the origin returns different languages. Excluding that value could send the wrong variant to another user.

Do not include a value merely because the origin wants to receive it. A unique tracking value can fragment one reusable response into thousands of cache entries. That lowers the hit ratio and increases origin work. Some CDNs separate the cache policy from the origin request policy for this reason.

HTTP uses the Vary response header to name request headers that select a representation. A cache must match those nominated fields before reusing the response without validation. Treat the cache key as a correctness boundary first and an optimization control second.

Freshness is not storage duration

A stored response is fresh while its age has not exceeded its freshness lifetime. A fresh response can normally be reused without contacting the origin. A response becomes stale after that lifetime.

Freshness does not guarantee that an object remains stored. A cache may evict an object to make room for other content. A long time to live, or TTL, permits reuse for a long period. It does not promise retention for that entire period.

Origins communicate caching policy through HTTP response headers. Common Cache-Control directives include:

• max-age: sets a freshness lifetime in seconds.
• s-maxage: overrides max-age for shared caches such as CDNs.
• public: allows shared-cache storage where a response would otherwise be restricted.
• private: restricts a response to a private cache.
• no-store: tells caches not to store the request or response.
• no-cache: allows storage but requires successful validation before reuse.
• must-revalidate: forbids reuse of a stale response until validation succeeds.

Provider configuration can alter or override origin headers. Confirm the effective policy for the CDN you operate. A configuration that forces a positive minimum TTL can conflict with restrictive origin directives.

Revalidation saves a transfer

Stale does not always mean unusable. A cache can send a conditional request to ask whether its stored representation still matches the origin.

An entity tag, or ETag, is a validator. The cache can send If-None-Match with the stored ETag. A 304 Not Modified response confirms that the representation remains current without sending the full body again. Last-Modified and If-Modified-Since provide a time-based alternative.

Revalidation still reaches an upstream server. It reduces response transfer size, but it does not provide the same isolation from origin latency as a fresh hit.

Updates need a strategy

Long freshness lifetimes improve reuse but delay visible changes at stable URLs. You have three broad controls:

1. Use a short freshness lifetime and accept more revalidation or origin requests.
2. Purge or invalidate a cached URL when its content changes.
3. Publish changed assets under a new versioned URL.

Versioned URLs work well for immutable assets. A filename such as app.4f3a.css can receive a long freshness lifetime because a changed file gets a new URL. The immutable directive tells clients that a fresh representation will not change during its freshness lifetime.

Purging is operationally useful, but broad purges can create a cold cache. A sudden wave of misses then reaches upper tiers or the origin. Prefer targeted invalidation when the provider supports it. Test how invalidation propagates through every cache layer.

Static and dynamic are policy choices

Images, style sheets, scripts, downloads, and video segments are common CDN content because many users request identical bytes. HTML and API responses can also be cached when their reuse rules are clear.

The labels static and dynamic are not sufficient cache policies. A generated response can be safely shared for a minute. A file can contain user-specific or sensitive data and must not enter a shared cache.

Ask these questions for each route:

• Does the response vary by user, authorization, cookie, language, device, or query value?
• Can two users safely receive the same stored response?
• How quickly must a change become visible?
• Can the origin validate a stale response?
• What happens when the origin is slow or unavailable?

If the answers are unclear, start with no shared caching. Add caching after you can define the key and freshness policy precisely.

Measure the whole system

The cache hit ratio is the proportion of cacheable requests served from cache. A higher ratio often means fewer origin requests, but it is not a complete performance score.

A high hit ratio can hide stale content, incorrect variants, or slow uncached routes. A low hit ratio can be expected for personalized traffic. Measure at least request volume, cache status, origin request rate, origin latency, response latency, error rate, and data transfer.

Inspect response headers during troubleshooting. The standard Age header estimates how long a response has been resident along the cache path since origin generation or validation. Providers also expose cache-status headers and logs. Interpret those fields with the provider's documentation because names and detailed behavior vary.

Where a CDN fits

A CDN is useful when users are distributed, content is reusable, origin capacity matters, or large transfers benefit from edge delivery. It can also provide transport security termination, request filtering, compression, and edge computation. Those features differ by provider and are separate decisions from HTTP caching.

A CDN is less useful when nearly every response is unique, requests must always reach the origin, or the added control plane is not justified. It also cannot repair slow database queries, incorrect cache headers, or an origin that the CDN cannot reach reliably.

Keep one mental model: route, key, freshness, fill, and observe. Routing chooses an edge. The key chooses a stored variant. Freshness decides whether reuse is allowed. A miss fills the path from an upstream source. Observability tells you whether the policy works.