Loading...
Loading...
Push CDNs, Pull CDNs, and edge caching strategies
Last topic left you with warm pooled connections at 0 ms plus 1 RTT, TLS 1.3 at one round trip instead of two, and six cold connections no longer burning 1.44 seconds of ceremony. But every exchange still pays the distance floor. Your server sits in Virginia, meaning a data-center region on the US east coast where your origin, which is the master server that holds the true files, lives. Your user sits in Tokyo, 6,700 miles of fiber away. Physics alone adds roughly a quarter-second round trip before your code even runs, because light in fiber needs about 200ms to cross the Pacific and back plus switching. Multiply that by forty images, three scripts, and two stylesheets, and your beautiful page loads like it is wading through mud. The rejected fix is backend tuning, but no index, pool, or handshake upgrade fixes the speed of light: 200ms of fiber delay survives all of it.
So stop fighting distance. Instead, put copies of your stuff in Tokyo ahead of time. That warehouse of copies around the world is a CDN, which is a content delivery network, meaning hundreds of edge servers that cache your files near users, and “the user downloads from nearby” is the whole idea. Everything below is details of that one move.
DNS, the internet's name lookup, sends the user to the nearest edge server, called a PoP meaning point of presence, not to Virginia.
Got a fresh copy? Serve it in 10–20ms. That is a cache HIT, meaning served from the edge without contacting origin.
A cache MISS means the edge lacked a fresh copy. The first unlucky visitor waits the full Virginia round trip while the edge grabs it from origin. Everyone after them gets the shelved copy in milliseconds.
Every copy carries an expiry time, called TTL meaning time to live. Short TTL means fresher content and more trips to origin. Long TTL means the opposite. Walk it: a 60-second TTL on a page hit 100 times a second means 1 miss and 5,999 hits per minute, a 99.98% hit ratio, while a 1-second TTL on the same page means 60 misses a minute and far more origin load.
Push means you upload each new file to the CDN yourself. Nothing is ever missing, but every deploy includes a shipping step you must not forget, and stale files linger until you push again.
Fits: small sites whose files change rarely
Pull means you point the CDN at your origin and walk away. Edges fetch whatever visitors actually request, then keep it for the TTL. The default choice for almost everyone, because storage and freshness manage themselves.
Fits: busy sites with lots of content
Nearby bytes beat fast bytes from far away. 250ms becomes 20ms
Static traffic never reaches origin at all at 95% hit ratio
Flood traffic gets absorbed across hundreds of PoPs before origin
One origin, worldwide presence, no new datacenters to run
Edge bandwidth routinely undercuts origin egress per gigabyte
Personalized pages and balances bypass the edge entirely
| Provider | Why people choose it | Reaches for it when… |
|---|---|---|
| Cloudflare, a CDN with bundled security | Generous free tier, security bundled in | Default choice for most projects |
| AWS CloudFront, Amazon's CDN | Lives inside AWS, runs code at the edge | Everything already runs on AWS |
| Akamai, the oldest large CDN | Biggest network, enterprise tooling | Media at massive scale |
| Fastly, a developer-focused CDN | Near-instant purges, sharp analytics | Content changes by the minute |
A CDN earns its keep in one metric: hit ratio, meaning the share of requests served from the edge without touching origin. Well-tuned static sites sit above 95%, which means 19 of 20 requests never reach your servers. The math compounds fast: 10k RPS of 100 KB images is 10,000 times 100 KB, which is 1 GB/s or 8 Gbps of traffic, but at 95% hit ratio your origin sees only 5%, which is 50 MB/s. Miss that ratio by ten points and origin load doubles twice over, because each lost point of hits lands directly on origin. The rejected alternative is caching everything by URL to chase the ratio: one session cookie in the key drops it toward zero, and personalized HTML served to the wrong visitor is a breach, not a win.
| Hit ratio | Origin sees (of 10k RPS) | Verdict |
|---|---|---|
| 98% | 200 RPS, which a single server yawns at | Static assets with versioned filenames |
| 90% | 1,000 RPS, which needs a real fleet | Mixed content, short TTLs |
| 70% | 3,000 RPS, so you barely have a CDN | Personalized keys or constant purges. Fix cache keys |
The levers: versioned filenames such as app.a3f9.js, meaning the hash changes on every build so assets cache for a year safely, query-string discipline, where one tracking parameter can shatter the hit ratio by making every URL unique, and separating static from dynamic paths so the dynamic 10% never poisons the static 90%. Large customers routinely offload 90% or more of egress this way, and the savings show up directly on the bandwidth bill.
Stale edge content fails in the most embarrassing way: the deploy went fine, origin is correct, and half the world still sees last week's price. Purges, meaning forced edge invalidations, propagate in seconds to minutes depending on the provider, with near-instant on some and tens of seconds on most, and during that window users compare screenshots. Worse is the thundering herd on expiry, meaning many edges refetching at once: a viral image TTL lapses across hundreds of edges at once, and origin gets hundreds of simultaneous refetches for the same byte. What breaks first is origin, drowned by synchronized misses rather than user volume.
Static bytes now ride 10 to 20 ms from the edge at 95% hit ratio, with versioned filenames caching for a year and surrogate keys purging one tag instead of a thousand URLs. But the dynamic half still runs on origins that drown: personalized pages bypass the edge entirely, and 3,000 RPS of misses lands like no CDN at all. Which server takes the next dynamic request, and who decides before the origin melts?