Content Delivery Networks: Bringing Content Closer

The problem caching alone can't fix

The first guide in this rung hammered home an uncomfortable truth: distance is latency, and you cannot beat the speed of light. A request to a server 15,000 km away pays a fat propagation delay on every single round trip, and a web page is a long conversation of round trips. The second guide showed how HTTP caching fights back — by keeping a local copy so a fresh request never leaves your machine, or returns a tiny 304 instead of the whole file. Caching is powerful, but it has a blind spot.

That blind spot is the cold cache. A browser cache or a shared forward proxy only helps for content someone has already fetched. The very first visitor to a page — or the first in a city, or the first after the content changed — finds an empty cache and has to make the full long-distance trip to the origin server anyway. For a popular video site with millions of distinct objects and constant updates, an enormous fraction of requests are cold. Caching reduces repeat trips beautifully; it does almost nothing for the first trip, and the first trip is exactly the one crossing the ocean.

So here is the question a content delivery network answers. Instead of waiting for users to fill caches near them, what if the content provider pushed copies out ahead of time — into machines physically close to users all over the world — so that even the first visitor in a region finds the answer waiting just down the road? That is the whole idea, and the rest of this guide unpacks how it actually works.

A chain of local warehouses

Picture a global retailer. It could ship every order from one giant factory, paying days of transit for each parcel — that is the single origin server. Or it could build hundreds of regional warehouses, each pre-stocked with the popular items, so most orders ship from a depot an hour away. A content delivery network is exactly that second design for web content. The retailer's central factory is the origin server; the warehouses are edge servers (also called surrogate or cache servers), scattered across thousands of locations worldwide, each holding copies of the content.

An edge server is, at heart, a reverse proxy — the same pattern from the last guide, just deployed at planetary scale. A reverse proxy stands in front of the origin and answers on its behalf; the client thinks it is talking to the real site. The CDN operator places these reverse proxies inside or near the networks where users live — in big city data centres, and often directly inside an ISP's network. When you ask for an image, you reach the edge server, not the distant origin, and your round-trip time drops from hundreds of milliseconds to a handful.

How content reaches the edge

Edge servers fill up in two complementary ways. The common one is pull: the edge starts empty, and the first time a user in its region asks for an object the edge doesn't have, it fetches it once from the origin, hands it to the user, and keeps a copy for everyone after. This is lazy and cheap — popular content naturally ends up cached everywhere it's wanted, and obscure content never wastes space. The less common one is push: for big planned events, the provider proactively pre-loads chosen files onto edges before the rush, so that even the very first viewer hits a warm cache.

Notice that pull turns the cold-cache problem into a one-time cost per region instead of a per-user cost. Without a CDN, ten thousand users in Tokyo each make their own long trip to an origin in Virginia. With a pull CDN, only the first Tokyo user pays the long trip; the edge serves the other 9,999 from across town. The metric that captures this is the cache hit ratio — the fraction of requests an edge can answer from its own copy. A well-run CDN edge often answers well over 90% of requests locally, which is why the origin barely breaks a sweat even under huge load.

Finding a nearby edge: the DNS trick

We've placed thousands of edge servers worldwide. But your browser only knows a name like images.example.com — how does it end up talking to the right edge, the one nearest you, rather than one in another hemisphere? The most widespread answer reuses a piece of machinery you already met: the Domain Name System. The trick is that the same name can be made to resolve to different IP addresses depending on who is asking and from where.

Here's the choreography. When you look up images.example.com, the lookup is delegated to the CDN's own authoritative name server. That server sees roughly where the request came from — often inferred from the IP address of your DNS resolver, sometimes refined by an EDNS extension that passes a slice of your real address. It then picks an edge server it judges to be close to you and fast, and returns that edge's IP address as the answer. Your browser, none the wiser, simply connects to the address it was handed. The same global name silently steers each user to a different local machine.

Two users, same name, different edge IP returned by the CDN's DNS:

  User in Tokyo                          User in Frankfurt
     |  "images.example.com?"               |  "images.example.com?"
     v                                      v
  CDN authoritative DNS  --- picks --->  CDN authoritative DNS
     |  sees ~Japan                          |  sees ~Germany
     v  returns 203.0.113.10 (Tokyo edge)    v  returns 198.51.100.7 (Frankfurt edge)
     |                                       |
     v                                       v
  HTTP GET to Tokyo edge (a few ms)      HTTP GET to Frankfurt edge (a few ms)
     (origin in Virginia is never touched on a cache hit)

Walking the whole request end to end

Let's trace one image request from click to pixels, to see every piece working together. The first user in a region pays a little extra; everyone after them coasts on the warm cache they left behind.

1. Your browser needs images.example.com. It asks its DNS resolver, which (after the usual root → TLD → authoritative chain) reaches the CDN's authoritative server.
2. The CDN's DNS notes roughly where the request came from and returns the IP of a nearby edge server, with a short TTL so the choice can be revised later.
3. Your browser opens a connection to that edge — a short round trip away — and sends an ordinary HTTP GET, exactly as if it were the origin.
4. Cache hit: the edge already holds a fresh copy (still within its Cache-Control lifetime), so it replies straight away. This is the fast common case, and the origin is never contacted.
5. Cache miss (you're the first, or the copy expired): the edge fetches once from the origin across the ocean — possibly sending an ETag conditional request and getting a cheap 304 if its stale copy is still valid — then serves you and stores the copy for the next visitor.

Step back and admire the division of labour. DNS solved finding a nearby edge; the reverse-proxy edge solved serving content close to you; HTTP caching with Cache-Control and ETags solved keeping those copies fresh without re-downloading everything. None of these mechanisms is new in this guide — the CDN is what you get when you wire the pieces from the earlier rungs together at global scale. That is the real lesson: big systems are usually familiar parts, arranged cleverly.