Content Delivery Networks (CDN)

A fleet of edge servers near users that cache content, so requests are served locally in milliseconds instead of crossing the world to the origin.

9 min read Watch it move Build it

Latency grows with distance — light in fiber crosses an ocean in tens of milliseconds, and every round trip pays that tax. A CDN (content delivery network) fixes this by moving the content closer: a fleet of edge servers placed near users worldwide, each serving cached copies so the request never has to travel to the far-off origin.

Edge PoPs and geography

A CDN operates hundreds of points of presence (PoPs) — clusters of edge servers in data centers spread across cities and continents. When a user in Tokyo requests an image, DNS (or anycast routing) steers them to the nearest PoP rather than the origin in, say, Virginia. Distance drops from thousands of kilometers to a local hop, and latency falls from ~200 ms to a few.

First miss, then hits

1First user in a region requests /logo.png → the local edge has no copy: a cache miss.
2The edge fetches /logo.png from the origin once, stores it, and returns it.
3Every later user near that PoP gets a cache hit — served locally in milliseconds, with no origin traffic.
4The origin now serves *one* request per region instead of one per user — the CDN absorbs the fan-out.

Offload is the second win

Latency is the obvious benefit, but shielding the origin is just as valuable: a viral file might be requested millions of times yet hit the origin only once per PoP. The CDN turns a traffic spike into a handful of origin fetches.

TTL and freshness

The origin controls how long an edge may serve a cached copy via the `Cache-Control: max-age` header — the TTL. While within TTL the copy is *fresh* and served with zero origin contact. Once the TTL elapses the copy is *stale*, and the edge revalidates with the origin (often a cheap 304 Not Modified if nothing changed) or refetches. Long TTLs maximize hit rate; short TTLs keep content current.

Cache invalidation

Caching means the world can hold a stale copy after you've changed the file — so you need a way to force-refresh. Two approaches dominate. A purge tells the CDN to drop a URL from every edge, so the next request refetches from origin (correct, but propagation isn't instant). Better is cache-busting with versioned URLs: ship app.a1b2c3.js instead of app.js, give it a one-year TTL, and change the filename whenever the content changes — the new URL is simply a new object, so there's nothing to invalidate.

"There are only two hard things..."

Cache invalidation is famously one of computing's hard problems. Prefer immutable, content-hashed URLs over purging mutable ones — you sidestep the whole timing problem because a changed file is a new URL, not a stale entry.

OperationTimeSpace

Cache hit (edge) · served from nearby PoP~1–10 ms—

Cache miss (origin fetch) · cross-region round trip, once per region~100–300 ms—

Check yourself

What is the main reason a CDN reduces load on the origin server?