Networking & Delivery
CDN
Server processing time was never the bottleneck for a user on the other side of the planet, the trip there and back was, and the hard part isn't caching, it's knowing when to stop trusting the cached copy.
Networking & DeliveryIntermediate5 min readPrerequisites: Caching
After this lesson, you should be able to:
- Explain what a CDN actually removes, network round-trip distance, versus what it doesn't, server processing time.
- Apply the TTL-versus-invalidation trade-off to a globally distributed set of edge nodes instead of one cache instance.
- Distinguish what's safe to cache at the edge, identical-for-everyone static assets, from what isn't, personalized responses.
- Recognize that purging a cached edge copy doesn't happen everywhere at once, propagation takes real time.
At a Glance
- A server that answers in 5ms can still take 300ms to reach a user across an ocean, because the trip itself, not the processing, is what's slow.
- A CDN fixes that by keeping copies of content physically close to users, not by making the origin server faster.
- The hard part isn't caching the content, it's knowing what's even safe to cache, static assets, not personalized responses, and purging a stale copy fast when the original changes.
01 The Problem
A company's marketing site runs on a single origin server in one US region, and the server itself is fast: it renders a page in 5ms. A user in Singapore still waits 300 to 400ms just for the page to start arriving, because every request physically travels there and back across the ocean, more than once for a full page load, DNS, the TCP handshake, TLS, the request itself, and the speed of light in fiber sets a hard floor on that round trip no matter how fast the origin responds.
Where the time for a distant user actually goes
Optimizing the origin server further, faster code, more caching at the database layer, bigger instances, doesn't touch any of that. The Singapore user is still waiting on the same number of trips across the same distance. Putting copies of the site's content on servers physically near Singapore fixes the distance problem, but creates a new one: the site has a pricing page that updates for a flash sale, and if the cached copy sitting in Singapore doesn't know the price changed, users there see the old price for however long that copy decides to hold onto it. The same staleness problem caching always has, just spread across dozens of physical locations instead of one.
This is a CDN. It solves the distance problem completely. It just moves "is this copy still right" to a much bigger, more physically distributed version of the same question.
02 What It Is
A CDN, content delivery network, is a set of servers, edge nodes, spread across many physical locations, that cache copies of content close to where users actually are, so a request gets answered from a nearby edge node instead of traveling all the way to the origin. The origin stays the source of truth. Edge nodes hold copies, populated the same cache-aside way any cache is: the first request for something at a given edge node misses, fetches from the origin, and caches it there for the requests that follow from nearby users.
Not everything is safe to put on an edge node. A static asset, an image, a stylesheet, a JS bundle, is identical for every user, so caching it anywhere is safe. A personalized response, an account dashboard, a page that greets someone by name, is different per user, and caching it at an edge node risks handing one user's page to a different user who happens to hit that same cached copy next. The real work of using a CDN well is drawing that line correctly, and purging or shortening the TTL on anything that crosses it.
In Plain Terms
A chain of copy shops keeps duplicate copies of a popular textbook on hand in every city so students don't have to mail-order it from the one warehouse that actually stocks it. That works perfectly for a textbook that doesn't change. It stops working the moment the publisher issues a corrected edition and the shop in one city forgets to swap out its old copies. A student walks out with outdated information, confident it's current, because nothing about the shop looks any different from the one that already updated.
03 How It Works
Rendering diagram…
04 Trade-offs
| Static assets (images, CSS, JS) | Personalized / dynamic responses | |
|---|---|---|
| Safe to cache at the edge? | Yes, identical for every user, no risk in serving a cached copy to anyone | Not by default, caching one user's response risks serving it to another |
| TTL | Can be long, hours or days, especially with a version-fingerprinted filename that makes staleness a non-issue | Has to be short or zero, or scoped per-user with a carefully designed cache key |
| Invalidation cost | Low: a new deploy usually ships a new filename, so old cached copies just age out unused | High: a change needs to purge or bypass the cache correctly, or a stale or wrong response gets served |
| What goes wrong when treated the same | N/A, this is the safe case | One user's private data cached and handed to a different user at the same edge node |
Watch out
It's tempting to treat a CDN as a switch you flip: cache everything, site's faster, done. Caching a response that varies per user is the actual danger, not a performance footgun but a correctness and privacy one. A cache key that doesn't account for who's asking can serve one user's account page, their name, their data, their session, to the next stranger who hits the same edge node. And purging a change doesn't happen everywhere at once, propagation across every edge location takes real time, so "I purged it" and "every user worldwide now sees the update" are not the same moment.
05 Where You'll Actually See This
Neither case study puts a CDN in front of anything, and that's a fair reflection of their scope: both assume a single-region deployment. Caching's Redis-in-front-of-Postgres pattern solves a problem measured in milliseconds within one data center, not hundreds of milliseconds across an ocean. This article is that same TTL-versus-invalidation trade-off, just applied at a scale where "purge everywhere" means dozens of physical locations instead of one cache instance.
It's also a routing decision, the same shape as load balancers: a load balancer picks the best instance within one data center, a CDN picks the best edge location on the planet for a given user. Different distances, same underlying question, which nearby, capable node should actually answer this request.
How to reason about it
When asked why a CDN helps, don't just say "it caches stuff closer to users." Say what it actually removes, the network round trip, not server processing time, and say what you'd never put on it without a cache key that accounts for who's asking, anything personalized or private. An answer that treats every response as equally safe to cache at the edge describes what makes a CDN fast, not what keeps it correct.
06 Quick Check
A team profiles their origin server and finds it responds in under 10ms for every request, yet users in another region still report page loads that feel slow. The team spends a sprint optimizing server-side code further with no improvement. What did they miss?