CDNs
Put copies of your static content near users, so most requests never reach you.
What problem does CDNs solve?
A user 15,000 km from your servers pays 150 ms per round trip, no matter how fast your code is. For a page pulling 60 images, scripts and fonts, those round trips dominate the load time.
A CDN keeps copies at hundreds of locations around the world, so those requests are answered a few milliseconds away. And your origin stops serving the great majority of its traffic.
What CDNs costs you
Every concept in here states a cost. A technique with no price is a technique you have not understood yet — and naming the cost out loud is most of what separates a senior answer from a junior one.
When to reach for CDNs, and when not to
Use it when
- Any static file: images, video, CSS, JavaScript, fonts. This is a default.
- Public API responses that are the same for everyone and change slowly.
- Large downloads, where the bandwidth out of your origin is the real cost.
- Soaking up traffic spikes and flood attacks before they reach you.
Do not, when
- Personalised or logged-in responses, unless you are extremely careful about cache keys and Vary headers.
- Data that has to be current to the second.
- Write traffic. A CDN only helps reads.
How CDNs actually works
Cache headers decide whether any of this works. Cache-Control max-age says how long the edge and the browser may serve it without asking again. s-maxage applies to the CDN only, so you can let the edge hold something for an hour while browsers hold it for a minute. stale-while-revalidate lets the edge serve a slightly old copy while it fetches a fresh one in the background. That removes the slow request at expiry time, and it is an often overlooked directive.
The versioned-filename pattern solves invalidation properly, and it should be your default answer. Give every build file a content hash in its name, like app.9f3a2c.js, and set a one-year cache that never changes. The file never changes, so it never needs clearing. A deploy publishes new filenames, and the HTML that points at them is the only thing with a short TTL. Then clearing the cache becomes something you almost never do, which matters, because clearing worldwide takes time and is the slow path.
Private data at the edge is the failure to watch for. If a response differs per user, the cache key must include whatever it differs by, or two users share one response. Mark logged-in responses private or no-store, and set Vary deliberately. One wrong header here leaks one customer's data to another.
Beyond static files, most CDNs will also end TLS near the user, so the handshake round trips go to a nearby edge instead of the distant origin. They absorb flood attacks. And they run small pieces of code at the edge, for routing, login checks and A/B assignment, keeping those decisions close to the user.
For video, the CDN is not a speed-up but the delivery method itself. The file is cut into short segments at several quality levels, and the player picks a level per segment based on the bandwidth it measures. Every one of those segments is a cacheable static file, which is why this design suits a CDN so well.
- Assuming a purge is instant everywhere. It is not, and browser caches are out of your reach entirely.
- Caching a logged-in response with no per-user cache key.
- Long TTLs on unversioned filenames, which makes every mistake expensive to fix.
The CDNs follow-up an interviewer will ask
"You deployed a bad image and it is cached worldwide. How fast can you fix it?"
It depends on choices I made before the incident. If files are content-hashed, this is barely an incident. The new deploy points at a new filename, the HTML has a short TTL, and users get the right file within a minute without clearing anything. If the file sits at a fixed path with a long TTL, I have to purge it, and that spreads across hundreds of locations, taking anywhere from seconds to minutes depending on the provider. Some clients will also keep serving it from their own browser cache whatever I do at the edge, and I cannot purge that at all. That last part is why long browser TTLs on unversioned paths are a trap. The lesson I would carry into the design: version the files, keep the HTML TTL short, and treat purging as an emergency tool, not a normal workflow.
Your turn
What is the one type of response you must be most careful about caching at the edge, and what specifically goes wrong?
Learn it from the source
This page gets you interview-ready. These take you to where the idea is actually specified or measured — read them when you want the real depth.
- MDN — HTTP Caching ↗Cache-Control, s-maxage and stale-while-revalidate explained header by header.
- RFC 9111 — HTTP Caching ↗The specification behind those headers, for when a colleague insists otherwise.