Content Delivery Network

When a service is new, its servers live in one place. One machine in a US East data center, and the whole world calls that machine. Inside the same country nothing looks wrong. The problem shows up from the other side of the planet. A single round trip from Seoul to US East takes about 200 milliseconds, and opening one web page involves dozens of those round trips. Fetch 40 images and 10 scripts separately and distance alone piles up several seconds, whatever the connection speed.

So every conversation about overseas users landed in the same place. Marketing would say traffic from Japan is up but the bounce rate there is unusually high, engineering would answer that the servers are in the United States, and someone would suggest putting a server in Japan too. But a full copy of the stack in every country multiplies the deploys by the number of countries, and the work of keeping data in agreement by the same factor. That is doubling the operational load for 100 users.

What stood out was where the slow time actually went. Most of it went into files that go out identically to everyone rather than into screens that differ per person. The logo image is the same file whether it is viewed from Seoul or São Paulo. So instead of moving the whole server, move only the parts that are safe to copy and scatter them in advance. A content delivery network (CDN) is that idea turned into a product.

It takes three loads off at once: the delay distance creates, the traffic piling onto a single origin server, and sudden surges.

1. Distance — CDN providers install hundreds of edge servers in major cities around the world. When a visitor asks for a file, DNS, the system that turns a domain name into a server address, points them at the closest edge. A visitor in Seoul is served from the Seoul edge, and the round trip drops from 200 milliseconds to 10.
2. Load — when an edge holds the file, the origin server never sees the request at all. In a service where images and scripts make up 80 percent of all requests, traffic reaching the origin falls to a fifth, and the capacity left over goes to work that needs computing, like logins and payments.
3. Surges — if something gets picked up somewhere and traffic runs 30 times normal, the edges absorb most of it, so the service holds without adding origin machines in advance.

The mechanism has two states. An edge starts out holding nothing. The first visitor to ask for a file triggers one fetch from the origin, which the edge stores on its own disk and serves. That is a miss. Every visitor after that gets an answer from the edge without the origin being involved. That is a hit. The share of requests that are hits is the report card for the whole setup: 95 percent means it is earning its keep, 60 percent means something is misconfigured.

How long an edge keeps a file is decided by the origin, which labels the file on the way out. That is why file names carry versions. Ship app.9f3c1.js instead of app.js and the name changes whenever the contents change, so the edge treats the new name as a file it has never seen and pulls a fresh copy.

There are three ways to attack the distance problem without a CDN, and none of them replaces it outright.

1. More origin servers — add machines and put a load balancer in front. That is the device that spreads incoming requests across the machines standing behind it, sending each one to whichever has room. The load gets shared, but if all the machines sit in one region, the 200 milliseconds from Seoul stays exactly where it was.
2. Regional replicas — stand up a full copy of the stack per country. Distance shrinks and even computed requests get handled nearby, but keeping the separate regional datasets in agreement becomes your problem. You are the one who has to solve why a document written in Tokyo shows up in Frankfurt a few seconds later.
3. Shipping less — compress the images, bundle the scripts, strip the code nobody calls. It is the first thing to do when working on web performance, and it pays well. Still, cutting a megabyte down to 300 kilobytes does not change the fact that those 300 kilobytes travel from the other side of the world.

In practice nobody picks one of the three. Option 3 reduces how much goes over the wire, a CDN goes on top of that, and option 2 comes up for review once a region starts producing real revenue. A CDN is close to a reverse proxy scattered around the globe. A reverse proxy is a relay that takes requests for the servers behind it; put one at every edge, let it hold files too, and you have a CDN.

"First paint for Japanese users is four seconds. How much would a CDN take off that?"

A request to check whether distance is what is actually slow.

"We shipped, but users are still seeing the old screen. Can someone run a purge?"

The edges are holding old files and need to be cleared by force.

"Our hit rate is only 62 percent. Let's start with the cache settings."

Too many requests are still reaching the origin, so the CDN is not earning what it costs.

When signups from Japan and Singapore started climbing at Pagedeck, Ravi brought the bounce rates by region. Domestic first paint was 1.2 seconds; Japan was 3.9 and Singapore 4.6. Theo found most of that time went to downloading the editor scripts and icon files.

Instead of moving the servers, he put just those files on a CDN. Two weeks later Japan was at 1.6 seconds and Singapore at 1.9. What remained belonged to document requests that still travel to the origin, and that went down as next quarter's work.

It is easy to assume a CDN makes the whole site faster. It gets introduced as a speed tool, so the expectation is natural. But the only thing an edge can answer on its own is a file that is identical for everyone. A signed-in user's document list differs per person, so that request goes to the origin and back, and if it is slow because of a database query, a CDN changes nothing about it. Miss this and you conclude the CDN did nothing while walking past the real cause for another month.

The second one is that you attach it once and never touch it again. Plenty of providers configure it automatically, which makes it look that way. In reality, getting the retention period wrong means shipped changes go unseen for days, or worse, land halfway. When some visitors have the new script and some have the old one, the screen breaks for a subset of users, and because nobody can reproduce it, finding the cause takes days.