CDN Architecture and Caching

A content delivery network, or CDN, is a distributed layer of servers placed close to users. Its job is to answer requests for web content from an edge location instead of forcing every request back to the origin server. That shortens round trips, reduces load on the origin, and gives the site more capacity during traffic spikes.

A typical request starts with DNS. When a browser asks for a site that uses a CDN, the authoritative DNS records usually point the hostname at the CDN rather than directly at the origin. The CDN then chooses an edge location, often based on the client resolver IP, network topology, current load, health, and routing policy. The browser connects to that edge server, performs TLS there, and asks for the asset.

If the requested object is already cached at the edge and still fresh, the CDN can return it immediately. This is a cache hit, and it is the fast path. If the object is missing, expired, or bypassed by policy, the edge fetches it from an upstream source. That source may be a regional cache, a shield layer, or the origin server itself. The returned response can then be stored at the edge for later requests. This is a cache miss.

The cache key matters more than many teams expect. A CDN must know whether two requests should share the same cached object. The key may include the path, query string, host, selected headers, cookies, device hints, or compression format. A poor key design causes two opposite problems. If the key is too broad, users may receive the wrong variant, such as another user's personalised page. If the key is too narrow, the hit rate collapses because the CDN stores too many near-duplicate copies.

Freshness is controlled with cache directives such as Cache-Control, Surrogate-Control, Expires, and explicit CDN rules. A long time to live improves speed and origin offload, but it also makes updates harder to roll out instantly. Purge and invalidation APIs exist for this reason, yet they are not magic. Large invalidations can take time to propagate, and some clients or intermediate caches may still hold stale copies. Many CDNs therefore support stale-while-revalidate or stale-if-error, which lets the edge serve slightly old content while it refreshes in the background or while the origin is unhealthy.

Modern CDNs do more than cache images and JavaScript bundles. They often terminate TLS, compress responses, convert image formats, enforce rate limits, block some attacks, and run lightweight edge code. Dynamic content can also benefit when the CDN caches safe fragments, reuses origin connections, or executes logic near the user. Still, truly personalised or strongly consistent data usually cannot be cached for long without careful design.

There are important failure modes. If the origin sends cacheable private data by mistake, the CDN can amplify that bug globally. If cache invalidation is slow, users may see mixed versions of a deployment. If the CDN is misconfigured to trust unclean headers, cache poisoning becomes possible. A CDN also cannot beat the laws of physics for uncached work. On a miss, the request still has to travel back to the origin, so poor origin performance remains visible.

In practice, a CDN works well when teams treat it as part of the application architecture rather than a simple traffic switch. The biggest gains come from designing cacheable responses, stable URLs, safe cache keys, and explicit freshness rules. When that is done properly, the CDN becomes a distributed performance and resilience layer in front of the site, not just a nearby copy of static files.