A server in one data center is physically far from most of its users, and distance itself costs time no amount of bandwidth fixes. A CDN's actual job is caching content at edge locations near users, so most requests never travel to the origin at all.
3 min read
Light in fiber-optic cable travels at roughly two-thirds the speed of light in a vacuum — a genuine physical limit, not an engineering shortfall. A round trip between New York and Singapore costs on the order of 200-plus milliseconds minimum, purely from the distance, before any server-side processing even starts. No amount of server optimization fixes distance — the only fix is moving the content physically closer to the user.
A CDN operates many edge locations — servers distributed geographically close to real users — and caches copies of your content at each one. A user in Singapore requesting a static asset gets it from a nearby edge server, not from your origin server that might be in Virginia, cutting that request's latency dramatically.
The first request for a piece of content from any given edge location is a
cache miss — the edge server doesn't have it yet, fetches it from the
origin, serves it, and stores a copy. Every request after that (until the cache
entry expires) is a cache hit — served entirely from the edge, no trip back
to the origin at all. This is exactly why the origin server's load and the CDN's
Cache-Control/TTL configuration matter so much: a well-cached, mostly-static
site might have the vast majority of its real traffic never reach the origin.
Static assets (images, CSS, JS bundles, especially ones with a content hash in
the filename) are ideal CDN candidates — they never change without also changing
their URL, so caching them indefinitely is completely safe. Personalized or
frequently-changing content (a logged-in user's dashboard, real-time data) is
much harder to cache safely — caching one user's personalized page and serving it
to a different user is a real, serious bug class, which is why Cache-Control: private and no-store exist specifically to opt sensitive or personalized
responses out of shared caching.
Modern CDNs (Cloudflare, Fastly, AWS CloudFront) increasingly sit in front of everything, including fully dynamic API traffic, and take on jobs beyond pure caching: TLS termination (from the previous two lessons), DDoS mitigation and rate limiting at the edge before malicious traffic ever reaches your infrastructure, and even running actual application logic at the edge ("edge functions") to personalize a response without a full round trip to the origin.
A CDN adds a genuinely useful layer of indirection, but it's still a layer: purging a stale cache entry across every edge location isn't always instant, and debugging "why is the user seeing old content" now has one more possible cause (a cached edge response) beyond the usual suspects (browser cache, application bug). Understanding the cache-hit path explicitly is what turns that into a five-minute diagnosis instead of a confused guessing session.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. Why doesn't increasing bandwidth fix latency caused by physical distance?
2. What actually happens on a CDN cache miss?
3. Why is caching a personalized, logged-in page at a CDN edge risky?
Networking Fundamentals