Latency is a function of distance. So what if your servers were everywhere at once — close to every user no matter where they are? That's the trick the entire commercial internet runs on. Time to look inside.
Remember Module 08? Light moves at about 200km/ms through fiber. London to Tokyo round-trip is ~210ms minimum, and that's the floor — engineering can shave the overhead above it, but the floor itself is set by physics. So when your servers live in Virginia and your user lives in Sydney, every single request pays that distance tax. Page loads feel slow. Apps stutter. Bounce rates rise. The internet has a geography problem.
That's just one request. A typical web page loads 60-100 files (HTML, CSS, JS, images, fonts). A user in Sydney waiting on Virginia could spend seconds just on accumulated network latency. There's nothing wrong with the code. Nothing wrong with the server. The user is just too far from the data. The only fix is to move the data closer. Which, it turns out, is exactly what a CDN does.
A Content Delivery Network is a distributed network of caching servers — called edges or PoPs (Points of Presence) — spread across the planet. When your user in Sydney requests an image, the request doesn't go to Virginia. It goes to the Sydney edge. If the edge has the file cached, it returns it in 10ms. If not, it fetches from your origin once, caches it, and serves every Sydney user from local storage from then on.
That diagram shows six edges. A real CDN has hundreds. Cloudflare has 300+ data centers worldwide. Akamai has over 4,000 locations. The point isn't to have one giant cache — it's to have thousands of small caches, each within milliseconds of some population of users. Your origin server might still be a single box in Virginia, but to a user in Mumbai, the website effectively lives in Mumbai.
How users find the nearest edge is itself clever: it's done with the same Anycast trick we mentioned in M.11. The CDN announces the same IP address from hundreds of locations, and BGP routes each user to the closest one automatically. No client-side intelligence required. To your code, it just looks like a normal HTTP request — but the response comes back ten times faster than it should.
CDNs are caches, so the cache rules from Module 07 still apply: you can only cache something safely if it's the same answer for everyone (or everyone in some segment). This works beautifully for static content — a CSS file looks the same to every user. It works terribly for per-user content — your bank balance shouldn't be cached at a public edge. The skill is knowing what lives in which category.
max-age=31536000, one year) by including a hash in the filename — app.a3f2b8.js. Easy win.stale-while-revalidate so users see a cached copy while a fresh one is fetched./api/products?page=1 as a different key than page 2.Cache-Control: private or no-store. The HTML hits origin; the static assets within it still benefit.Cache-Control: no-store or private.The control mechanism is the same set of HTTP headers we touched on in M.07: Cache-Control on responses tells the CDN what to do. public, max-age=3600 = "cacheable for anyone, fresh for an hour." private, no-store = "this belongs to one user, don't cache anywhere." Most production setups define cache rules per route or per file pattern at the CDN level — and getting them right is one of the easiest performance wins in any system.
Five users worldwide — Tokyo, London, Sydney, São Paulo, Mumbai — all request the same JS file from an origin in Virginia. Toggle between Without CDN and With CDN and hit Send batch. Watch what happens to the latency numbers. The first batch with CDN warms the edges (still kinda slow). Every batch after that — a different story.
Without a CDN, every user pays the round-trip cost to Virginia. With a CDN, the first batch warms the edges (the edge must still fetch from origin once), but subsequent batches are answered locally. Watch the average latency collapse from ~160ms to under 15ms.'
The caching story is the original CDN story, and it's still the headline feature. But the same global edge footprint turns out to be useful for several other jobs that have nothing to do with caching — and that's why CDNs have become a layer of infrastructure most production systems can't really do without.
When an attacker tries to flood your origin with traffic, the CDN's hundreds of edges absorb the attack across their entire global capacity. A 1 Tbps flood that would kill your origin instantly becomes background noise distributed across the edge fleet. This is the second-most-common reason teams adopt a CDN.
The expensive TLS handshake (Module 03!) happens between user and the nearby edge, not user and your distant origin. Edges hold your SSL certificate and decrypt incoming traffic, forwarding plain HTTPS to your origin over a maintained connection. Cuts visible page-load times by 100-200ms.
Edges can resize images, convert formats (JPEG → WebP/AVIF), and minify JS/CSS on the fly. Same source file, different optimized versions per browser. Some edges even rewrite HTML to prefetch resources. Faster than doing it yourself — and zero deploy.
Newer CDNs (Cloudflare Workers, Fastly Compute, Vercel Edge) run your code on every edge — A/B testing, auth checks, redirects, lightweight APIs. The user gets a response from 30ms away without your origin ever waking up. The line between CDN and compute platform is blurring fast.
The honest summary is that "CDN" has become a misleadingly narrow name. Modern providers like Cloudflare, Fastly, and CloudFront sell themselves as edge platforms — caching is just job one. By the time you've gotten to scale, the CDN is doing a dozen things: serving cached assets, terminating TLS, blocking bots, redirecting old URLs, A/B testing, optimizing images, rate-limiting hot endpoints. The platform earns its line item.
You'll hear these in every architecture conversation involving a frontend that anyone outside your office uses.
public, max-age=3600, no-store, private. The dial that controls everything about caching behavior.Lock in the CDN intuition. Click an answer; the explanation drops in instantly.
You see the global cache clearly now. Statelessness is next — and it's what makes all this distribution possible.
CDNs are how the internet doesn't feel as slow as it actually is.
Physics makes long-distance requests slow no matter how fast your server is. The only fix is to put a copy closer to the user.
A CDN spreads your static content across hundreds of points of presence. Each user hits the nearest one — typically <20ms away.
TLS termination, DDoS protection, image optimization, edge compute. The global footprint is useful for far more than serving files.