CDNs and Edge Caching — Algorithmics

Your server is in Virginia. A user in Sydney is 16,000 km away.

Light in fibre travels about 200,000 km/s, and a request is a round trip. That is 160 ms before your server has read a single byte, and TLS needs two or three round trips before the request even starts.

No amount of server optimisation touches this. You cannot make a 500 ms page fast from one location.

distance to origin 12,000 kmdistance to nearest edge 80 kmedge hit rate 85%

direct to origin: 120 ms
via the edge: 19 ms
origin requests saved: 85%

One round trip over 12,000 km costs 120 ms in fibre alone, and TLS needs several. No amount of server tuning removes it — the only fix is to be closer, which is the entire product. Note also that a miss is slower than going direct: you pay both hops.

What lives at the edge

Static assets — images, JavaScript, CSS, video. The obvious case, and still most of the traffic.

Cached HTML. A page that is the same for everyone can be served from the edge entirely. This is what makes a static site feel instant everywhere.

API responses, where they are cacheable and short-lived. Even a 10-second TTL absorbs an enormous amount of load on a popular endpoint.

Compute. Cloudflare Workers, Lambda@Edge, Deno Deploy — run code at the edge, so personalisation does not force a trip to the origin. This is the interesting frontier, and it changes what “cacheable” means.

TLS termination. Even on a full miss, terminating TLS at the edge saves the handshake round trips over the long link, and the edge-to-origin connection is already warm.

Cache headers, which are the actual API

Cache-Control: public, max-age=31536000, immutable

For a fingerprinted asset (app.4f3a2b.js). A year, and immutable tells the browser not to revalidate even on reload.

Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=86400

For HTML. The browser does not cache it; the CDN caches for five minutes; and for a day after that the edge serves the stale copy immediately while fetching a fresh one in the background.

Cache-Control: private, no-store

For anything user-specific.

Invalidation

TTL expiry. No action needed, and you wait out the TTL.

Purge by URL. Explicit, immediate-ish, and requires knowing every affected URL.

Surrogate keys / cache tags. Tag responses (product-42) and purge the tag. This is the one that scales, because one product change may affect a listing page, a search result and a sitemap.

Versioned URLs. The most reliable of all: never invalidate, change the name. This is why build tools emit content hashes, and it is the only approach that works for the browser cache, which you cannot purge at all.

Beyond caching

Anycast routing. The same IP announced from hundreds of locations; BGP sends each user to the nearest. This is also the first line of DDoS defence — an attack is absorbed across the whole network rather than at one datacentre.

Connection reuse. The edge keeps warm, tuned connections to your origin, so even a miss skips the TCP and TLS handshakes over the long path.

Origin shield. A designated mid-tier cache that all edges consult before the origin, so a purge of a popular object does not produce hundreds of simultaneous origin requests. This is the stampede problem at CDN scale.