Content Delivery Networks (CDNs)

A CDN keeps copies of your content sitting near the people who ask for it, so distance stops being the thing that decides how fast your site feels. Whether that pays off at all comes down to how many people one copy can answer: enormously, when the bytes are identical for everybody, and close to nothing when every request deserves a different reply.

Picture a single printing press serving an entire country. For a poster everybody wants, that is an absurd arrangement: each reader mails in an order, the press runs off one more identical sheet, and the post carries it back across the country. Send the master to a print shop in every town instead and the whole problem dissolves, because one plate can serve a queue of any length and nobody is waiting on the mail.

Now make it a certificate with the reader’s own name on it. No local shop can print what it has never seen and could not have guessed, so every order travels back to the one press that holds the records. The shops are still there, still close by, still cheap to run, and for this job they contribute nothing except one more counter to queue at on the way.

Light in fiber travels at roughly two thirds of its speed in a vacuum, which works out to about one millisecond of round trip per hundred kilometres. A user in Sydney talking to a server in Virginia is around 16,000 km away, so physics alone charges them about 160 ms before a single byte of application work happens, and real routing, which never follows a straight line, pushes that past 200 ms in practice.

Nothing you do to the server moves that number. A faster database, a bigger instance, a tighter query, all of it is optimising the small slice of the bar that is not distance. Putting a copy of the response 50 km from the user is the only change that moves the dominant term, and that is the entire argument for a CDN.

One honest exception to the right-hand column: on a large CDN a forwarded request is not simply an extra hop. The edge terminates TLS next to the user, so the handshake’s several round trips are short ones, and it reaches the origin over already-open connections on the provider’s own backbone rather than whatever path the public internet picks that day. Sold as dynamic site acceleration, it is a real but modest win, and it is worth knowing the shape of it: you are shortening the path for uncacheable traffic, not removing it.

You ship a new version. The HTML is fresh, the server is fine, the logs are clean, and some fraction of your users see a broken, half-styled page. Their browser is loading new markup against a styles.css that an edge node fetched an hour ago and is contractually entitled to keep serving for another twenty-three.

A purge API fixes it after the fact, and every CDN has one, but it is a repair, not a design. The design is to never reuse a URL for different bytes: build output named app.4f9c2b.js changes its name whenever its contents change, so the old entry is simply never requested again and the new one has nothing stale to collide with.

That leaves exactly one file that must not be cached hard: the HTML that names the hashed assets. Give it a short TTL or revalidate it every time, cache everything it points at for a year, and the stale-asset problem stops existing rather than being managed.

A CDN is a genuine first line of defence. Repeat requests die at the edge, so a spike that would have flattened one machine is instead spread across a global network, and a large share of crude denial-of-service traffic never reaches the origin at all. Sites routinely report that the overwhelming majority of their requests never touch their own servers.

The trap is reading that number as headroom. The share the edge absorbs is the cacheable share, and the uncacheable remainder, logins, checkouts, searches, writes, grows with the spike just as fast as everything else. Ten times the traffic is also ten times the logins. The CDN divides origin load by a constant; it does not change what happens when the input goes up.