How Does a CDN Work? – Routing, Caching, and Origin Fetches
Follow a request through a content delivery network: how users reach a nearby edge, how cache keys work, and what happens on a miss.
A content delivery network answers requests from servers near the user. The mechanics divide into two questions: how a request reaches a nearby edge, and what that edge does when it arrives.
1. Reaching a Nearby Edge
Two mechanisms are used, often together.
DNS steering — the authoritative nameserver returns different addresses depending on where the query came from, sending each user toward a nearby location.
Anycast — the same address is announced from many locations, and internet routing delivers packets to whichever is closest by network topology.
Anycast is more responsive to routing changes; DNS steering allows finer policy. Both mean the address a client connects to says nothing about where the origin lives.
2. What the Edge Does First
The edge terminates TLS, so the handshake completes near the user rather than crossing the world. It then applies whatever rules the site configured — rate limits, firewall rules, bot management — before considering the content at all.
This is why a refusal can be issued in milliseconds and why error pages often carry the network's branding rather than the site's.
3. The Cache Key
An edge decides whether it already holds a response by computing a key, typically from the host, path, and query string — and optionally from headers such as language or device type when the site varies content by them.
Including too much in the key fragments the cache, so hit rates fall. Including too little serves the wrong variant to somebody. Tuning that key is most of cache configuration.
4. On a Miss
The edge fetches from the origin, stores the response according to its cache headers, and returns it. Response headers usually indicate whether the answer was a hit or a miss.
Where many edges miss simultaneously — a popular new object — an origin shield tier absorbs those fetches so the origin sees one request rather than hundreds.
5. Freshness and Invalidation
Objects expire on their TTL. Where content must change sooner, a purge invalidates it explicitly, and cache tags allow a group of related objects to be purged together.
Stale-while-revalidate lets an edge serve a slightly old object while fetching a fresh one, which keeps latency low at the cost of brief staleness.
6. Not Everything Is Cacheable
Personalised pages, authenticated responses, and anything varying per user are usually passed through. Static assets, public pages, and API responses with explicit cache headers are the cacheable majority.
Getting this wrong in either direction is consequential: caching a personalised page can serve one user's content to another.
7. What This Means When Fetching Pages
- A cached response may be older than it appears; check cache status headers.
- Content varies by region because edges serve region-appropriate variants.
- Refusals frequently originate at the edge, not the site.
- The connected address belongs to the network, so it reveals nothing about the origin.
8. Summary
A content delivery network routes users to nearby edges through DNS steering or anycast, terminates TLS there, applies site rules, and answers from cache or fetches from the origin.
Cache keys decide what counts as the same response, TTLs and purges decide freshness, and shielding protects the origin from simultaneous misses.