CDNs: Move the Bytes to the User, Not the User to the Bytes

The launch went out at 9am UTC. The hero image — one 400KB WebP — sat on a single origin in us-east-1, Northern Virginia. For everyone in the eastern US it felt instant. For the half of your audience in Sydney, Mumbai, and São Paulo, the page hung for two seconds on a blank rectangle while the browser dragged that image, byte by byte, across an ocean and back.

Nobody wrote slow code. The server responded in 8ms. The problem is that Sydney is roughly 16,000km from Virginia, and light in fibre doesn’t care how good your backend is. A single round trip is ~160–200ms before the first byte moves — and TCP plus TLS plus the actual transfer each pay that toll again. You cannot optimize your way out of geography. You can only stop making the user travel it.

The physics you’re fighting

Latency has a floor set by the speed of light, and it is not negotiable. Light travels ~200,000 km/s in fibre (slower than in vacuum). A packet from Sydney to Virginia and back covers ~32,000km — that’s ~160ms of pure propagation, before you add router hops, congestion, or a single byte of payload.

Now stack the handshakes. Opening an HTTPS connection is a TCP handshake (1 RTT) then a TLS handshake (1–2 RTTs). At 200ms per RTT, you’ve burned the better part of a second establishing a connection that hasn’t transferred anything yet. Do that from a PoP 20ms away instead and the same ceremony costs a tenth as much.

That reframes the problem, but it opens a dozen more — and the members-only continuation is where they get answered: how a request actually finds its nearest edge (anycast vs DNS routing), the HTTP-header cache mechanics and edge-serving code the PoP runs, push vs pull and the invalidation trap, edge compute and origin shielding, how Cloudflare, Akamai, Fastly, and Netflix really do it, plus the interview corner and a quiz to test yourself.