CDNs: moving the content closer

You cannot beat the speed of light

A request from Sydney to a server in Virginia crosses about 16,000 km of fiber. Even at light speed, the round trip costs about 200 ms, and the lesson 1-2 journey needs several round trips (TCP handshake, TLS handshake, then the request itself). Distance is latency, and no amount of server power fixes it.

A CDN (Content Delivery Network) fixes it the only way physics allows: by moving copies of the content closer to users. A CDN operates hundreds of edge servers around the world. DNS steers each user to the nearest edge, and the edge serves cached copies of the site's files:

• Cache hit: the edge already has the file (someone nearby requested it recently) and answers in ~20 ms.
• Cache miss: the edge does not have it, fetches it once from the origin (the site's real server), stores it, then serves everyone nearby from the copy.

What may a CDN store? Exactly what lesson 8-1 taught: responses marked public with a max-age. That is why those headers matter beyond your own browser. You can spot a CDN in response headers like X-Cache: HIT or Server: cloudflare.

How often the origin actually serves a file

About once every 5 minutes, when the Tokyo edge's copy expires and it re-fetches.

max-age=300 lets the edge reuse its copy for 300 seconds. Within each 5-minute window the Tokyo edge absorbs all 8,000-plus requests and the origin sees roughly one.

This is how a modest origin server survives enormous traffic. The CDN takes the flood and the origin takes a trickle, without any change to the application itself.

Note that the count is per edge rather than global. A site served from 200 edge locations sends the origin roughly 200 fetches per window instead of one, which is still nothing next to the traffic those edges absorbed.

Putting numbers on it

With max-age=300, an edge's copy expires every 300 seconds, so the origin serves that file to that edge about 3600 // max_age times per hour.

requests_per_hour = 100000
max_age = 300  # seconds

origin_fetches = 3600 // max_age
hits = requests_per_hour - origin_fetches
print("origin fetches per hour:", origin_fetches)
print("cache hit ratio:", round(hits / requests_per_hour * 100, 3), "%")

Output

origin fetches per hour: 12
cache hit ratio: 99.988 %

Reading the numbers

• 3600 // 300 is 12, one re-fetch per 5-minute window, which is the only origin traffic this file generates.
• The ratio is hits divided by total requests times 100, wrapped in round(..., 3) so the three nines survive instead of rounding to 100.
• This is the economics of CDNs in two lines. The origin handles 12 requests instead of 100,000, which is why a modest server can sit behind a front-page news story.
• The ratio barely moves if you change max_age to 60. Origin fetches rise to 60 and the hit ratio is still 99.94 percent, so a short freshness window costs far less than people expect.

The name for a first-request fetch

That event is a cache miss.

The edge fetches the file from the origin once, stores it while respecting Cache-Control from lesson 8-1, and subsequent nearby requests become cache hits until max-age runs out.

The opposite event, when the copy is already there, is called a hit, and you may literally see which one happened in a response header such as X-Cache: HIT.

Only one unlucky visitor pays for the miss, and everyone behind them gets the fast path. That asymmetry is why hit ratios in the high nineties are normal for static assets.

Sites sometimes warm caches by requesting key files from many regions right after a deploy, so real users never pay the miss at all. It is a cheap trick that turns the first visitor's slow load into a script's problem instead.