← Back to Caching and Performance

Content Delivery Networks (CDNs)

CDNs cache content at edge locations to cut latency and shield origins.

Caching and PerformanceCDNContent Delivery

A CDN, or content delivery network, is a distributed platform of edge servers that stores and serves content closer to users than the origin server does. The basic problem it solves is distance. If every image, script, download, and video segment must travel from one central origin to every user worldwide, latency rises, origin capacity becomes expensive, and traffic spikes become harder to absorb.

A CDN places copies of cacheable content in points of presence around the network. When a user requests an asset, DNS resolution or anycast routing sends that request to a nearby edge location. If the object is already cached there, the edge returns it immediately. If not, the edge fetches it from the origin or from an upper tier cache, stores it according to cache rules, and serves it onward. That mechanism reduces round trips to the origin and spreads load across many locations.

Caching policy is where most of the real engineering lives. A CDN decides whether two requests are equivalent by building a cache key, often from the URL plus selected headers, query parameters, or cookies. Time to live settings define how long an object may be reused before revalidation or refresh. Purge and invalidation APIs let teams remove stale objects before TTL expiry, but aggressive purging lowers hit rate and pushes traffic back to the origin.

Modern CDNs are not limited to static files. They often terminate TLS, apply web application firewall rules, block abusive bots, compress assets, optimise image formats, and support edge logic for lightweight request rewriting or personalisation. Some also offer origin shielding, where many edge locations fetch through a smaller intermediary layer to protect the origin from request storms.

The tradeoffs are straightforward but important. Cached content can go stale if invalidation is slow or cache keys are misconfigured. Personalised pages are hard to cache well because user specific cookies can explode the number of variants. Debugging becomes more complex because the client may be seeing content from an edge that differs from the current origin state. Cost models can also surprise teams if they optimise for low origin traffic but ignore high egress volumes at the edge.

A CDN is most valuable when it is treated as part of the application delivery architecture rather than as a magic speed box. Teams need explicit cache headers, versioned assets, clear purge behaviour, and metrics for hit rate, origin fetches, and edge errors. With that discipline, a CDN can improve latency, absorb bursts, and add a useful security boundary. Without it, the CDN still works, but it mostly caches confusion and delivers it very efficiently.