Content delivery networks
A Socratic walk-through of content delivery networks — reasoned out one step at a time, not lectured.
The question we started with
THE QUESTION #Why does a copy of a file stored near you make a distant website feel local?
A website's servers are in Virginia. You are in Lisbon. The page feels instant — as though the servers were down the road. Nothing was moved; the company still runs its application in Virginia.
The usual explanation is "there is a copy nearer you", which is true and explains almost nothing. Copies of what? Most of a modern page is generated for you personally. And why should a nearby copy matter so much, when the data would arrive at nearly the speed of light anyway? It is worth taking those two questions seriously, because the honest answer changes what you would build.
Reasoning it through
REASONING #Start with the physics, since it sets the floor everything else sits on.
Light in optical fibre travels at roughly two-thirds of its speed in vacuum: about 200 kilometres per millisecond. Lisbon to northern Virginia is around 6,000 kilometres as the crow flies, and the fibre path is longer. So a round trip costs near 60 milliseconds at best, and 90 to 110 in practice. It is a distance divided by a speed, and nobody optimises it away.
Now the step that turns a modest number into a large one. How many round trips does one HTTPS request need before a single byte of content arrives? The TCP handshake is one. The TLS 1.3 handshake is another — TLS 1.2 needed two. Then the request goes and the response comes back: one more. Three round trips before the first byte, and that is before counting slow start, which makes a large file need several further exchanges to reach full speed.
Multiply. Three round trips at a hundred milliseconds is three hundred milliseconds of pure waiting for one resource, and a page pulls dozens. Do you see what has happened? The distance has been amplified by the protocols, and the amplification is what a CDN actually attacks. Latency is not one tax; it is a tax charged repeatedly.
So place a server — a point of presence — in Lisbon. When it holds the file, all three round trips shrink to the few milliseconds of a local hop, and the page's assets arrive nearly at once. That is the cached case, and it is easy to see.
But now ask the harder question: what about the parts that cannot be cached? Your account page, a search result, an API call. The edge cannot answer those from a copy, and the origin is still in Virginia. Is the CDN useless for them?
No — and this part is genuinely counter-intuitive, so it is worth working through. The handshakes still terminate at the edge. Your browser opens its TCP and TLS connections to Lisbon, paying two fast local round trips instead of two slow transatlantic ones. The edge then reaches the origin over a connection it already holds open and keeps warm, often over the provider's own optimised backbone rather than the open internet. So even for entirely dynamic content, the number of long-distance round trips falls from three to about one. A CDN is therefore a connection-shortening device at least as much as a copying device — which is why sites with almost nothing cacheable still use one.
How does your request reach the Lisbon machine rather than one in Frankfurt? DNS-based steering answers your resolver with an address chosen for your approximate location. Anycast goes further: the same IP address is announced from many locations at once, and ordinary internet routing delivers your packets to the nearest — which is why the address you connect to may be identical to the one somebody in Tokyo uses.
Which leaves the question that decides whether any of this works: how does the edge know its copy is still correct? Through the freshness rules the origin states — a Cache-Control lifetime after which the copy is revalidated, and validators like ETag that let the edge ask "has this changed?" and get a cheap "no". Urgent changes can be purged across the network. And the technique that avoids most of the problem is versioned filenames: give each build's assets unique names, and a cached copy never needs invalidating because it is never wrong.
One measurement to hold on to: the cache hit ratio, the fraction of requests the edge answers without contacting the origin. It sets both the speed benefit and the origin's load, and a low one usually means the origin's own headers are the problem, not the network.
The analogy
THE ANALOGY #Think of a national library that lends by post, and a local branch that keeps copies of the books people around here actually ask for. Popular titles are on the shelf and you walk out with one. An obscure title still has to come from the capital — but you place the request at the desk you are already standing at, and the branch has a standing courier arrangement rather than you posting a letter and waiting for a reply before you can even place the order.
a library's copy is only correct until the book is revised and nobody at the branch would know, whereas an edge cache is governed by an explicit lifetime the publisher sets and can be purged deliberately — freshness in a CDN is a stated contract, not an assumption, and getting that contract wrong is the usual cause of a site serving yesterday's page.
Clarifying the model
THE MODEL #A few refinements.
Bandwidth is not the main story. It matters for large media, but for a typical page the bottleneck is the number of sequential round trips, not the width of the pipe — which is why a fast connection can still feel sluggish on a distant site.
And "nearby" means network-near, not map-near: a city a hundred kilometres away may route through a peering point in another country. CDNs sit at interconnection points for that reason, and the distance that matters is measured in round-trip time.
The economics run alongside the performance. Serving from the edge removes traffic from the origin, so a hit is cheaper than a miss on both counts — but the saving is entirely a function of hit ratio, and a badly configured cache leaves you paying for a CDN and for the origin's full load.
Finally, a CDN cannot fix a slow origin for uncacheable work. If your database query takes eight hundred milliseconds, the edge saves two round trips and nothing else — real, but bounded, and reaching for a CDN to mask an application problem is a common and expensive mistake.
A picture of it
THE PICTURE #How to readFollow the numbered arrows down the page and count how far each one travels. Steps 1 to 3 never leave Lisbon — handshakes and response all local, the cached case everyone pictures. Steps 4 to 7 are the case people assume a CDN cannot help, content unique to this reader; notice that only one arrow crosses to Virginia, because setup was paid locally and the edge already holds an open link. The closing note is the business model: a miss is paid once and becomes hits for everyone nearby.
What became clearer
WHAT CLEARED #The benefit is not that data travels faster, but that fewer sequential crossings are needed. Distance is charged once per round trip, and a single HTTPS request needs several, so a few thousand kilometres becomes a visible fraction of a second. An edge cache removes those crossings for anything it can hold a copy of, and — less obviously — removes most of them even for content it cannot cache, by terminating the handshakes locally and keeping a warm connection to the origin. What determines how much of that benefit you get is the freshness contract in your own headers, measured as a hit ratio.
Where to go next
ONWARD #- Why HTTP/3 over QUIC removes a round trip from connection setup, and what that leaves for a CDN to save.
Key terms
TERMS #| Term | What it means |
|---|---|
| Cache hit ratio | the fraction of requests answered at the edge without contacting the origin; it sets both speed and cost. |
Every term the collection defines is gathered in the glossary.