Content Delivery Networks (CDNs): Speed by Proximity

Caching stores answers to avoid repeating work. A CDN (Content Delivery Network) takes that idea and adds geography: it caches your content on servers spread around the world, so each user is served from one physically near them. The result is dramatically faster delivery — and a huge load lifted off your own servers. It's how the same website feels fast in Tokyo, London, and São Paulo at once.

The problem: distance costs time

No matter how fast your server is, there's a limit it can't beat: the speed of light. Data takes time to travel, and a user on the other side of the planet from your server pays that travel cost on every round trip.

A single server in one location is, by definition, far from most of the world. You can't make light faster — so the only real fix is to move the content closer to the user. That's the entire premise of a CDN.

The edge: a global cache network

A CDN is a network of edge servers in many locations worldwide. Your content is cached on these edges, and when a user makes a request, it's served from the nearest edge that has it — not from your distant origin server.

The first request in a region may travel to your origin (your actual server) to fetch the content, but the edge then caches it — so every subsequent user in that region gets it locally and fast. Popular content ends up cached near everyone who wants it.

What belongs on a CDN

CDNs are perfect for content that is the same for everyone and changes rarely — so a single cached copy serves many users for a long time:

What doesn't fit the edge is personalized or constantly-changing data — your account page, a live feed, anything unique per user. Those still come from your origin (or a dynamic cache). The CDN's sweet spot is the heavy, shared, static stuff — which, on most sites, is the bulk of the bytes.

Offloading the origin

Speed for users is half the win; the other half is load taken off your servers. Every request the edge serves from cache is a request your origin never sees.

So a CDN does double duty: it cuts latency and shields your origin from the firehose, often turning what would be overwhelming traffic into a trickle of genuinely dynamic requests.

The catch: invalidation, globally

You saw the hard part of caching coming. If your content is cached on edge servers all over the world, what happens when it changes? A new version of a stylesheet, an updated image — the old one may still be cached on hundreds of edges.

CDNs handle this with the same tools from the caching chapter, now distributed: TTLs that expire edge copies after a set time, and purge/invalidation commands that tell the network to drop a cached item everywhere. A common trick for assets is versioned filenames (e.g. app.v2.js) so a change is simply a new URL that was never cached — sidestepping invalidation entirely. The lesson repeats: caching's hard problem doesn't disappear at the edge, it just gets bigger, so plan for how cached content gets refreshed.

Recap

• A CDN caches content on edge servers worldwide, serving each user from a nearby one.
• It exists because latency is bounded by distance — the only fix for far-away users is to move content closer.
• It's ideal for static, shared content (images, video, scripts, styles), not per-user dynamic data.
• It offloads your origin, absorbing most requests so your servers handle only the dynamic remainder.
• Edge invalidation (TTLs, purges, versioned URLs) is the distributed version of caching's hard problem.

We've cached static content at the edge. But dynamic data — the stuff that can't live on a CDN — needs caching too, at scale. Continue to Caching at Scale.