Module 06 · Caching · Lesson 5 of 8
Content delivery networks (CDN)
A CDN is a cache that lives at the network edge: hundreds of points of presence that serve your content from a few milliseconds away and shield the origin from most of the traffic.
Why it matters
Light takes about 70 milliseconds to cross the Atlantic and back. No amount of server tuning beats geography. For anything a user downloads (images, scripts, video segments, whole pages) the fastest server is the nearest one, and the cheapest request is one that never reaches your data centre. A CDN gives you both without you running servers in 200 cities.
The idea
A CDN is a distributed cache operated by someone else. Each point of presence (PoP) is a cluster of edge servers in a city. DNS or anycast routing sends each user to a nearby PoP. The edge checks its cache; on a miss it fetches from your origin, stores the response, and serves it. The next user in that city hits.
What controls the cache
The origin tells the CDN how to behave through HTTP headers. Cache-Control: public, max-age=86400 says anyone may cache this for a day. s-maxage targets shared caches like the CDN specifically. no-store forbids caching. stale-while-revalidate lets the edge serve an expired copy while it fetches a fresh one in the background, so users never wait on a miss.
The cache key decides what counts as "the same request". By default it is the URL. Vary it on a header or cookie and you split the cache; forget to vary on something that changes the response and users see each other's data. Keep cache keys minimal and deliberate.
Purging removes content before its TTL ends, by URL, by tag, or everything. Purge latency across a global network is seconds, not milliseconds. For instant changes, use versioned filenames (app.3f9c1.js) with a one-year TTL and change the reference instead of purging.
Pull versus push
| Pull (origin pull) | Push (pre-upload) | |
|---|---|---|
| How content gets to the edge | Fetched from origin on first miss | Uploaded to the CDN ahead of time |
| Origin must stay online | Yes | Not for pushed assets |
| Fits | Websites, APIs, long-tail content | Large releases, video libraries, game patches |
| Storage cost | Only what is requested | Everything uploaded |
| Default for | Almost every web app | Media and software distribution |
Beyond static files
Modern CDNs cache dynamic responses too: an API GET with a 10-second s-maxage absorbs a traffic spike on a product launch. They terminate TLS at the edge, which cuts handshake time, and they run code at the edge (Cloudflare Workers, Lambda@Edge, Fastly Compute) for personalisation, A/B routing and authentication before the request ever reaches you. An origin shield is an extra regional cache layer that collapses misses from many PoPs into one origin request.
Trade-offs
A CDN hides your origin from load, which means a configuration mistake that turns caching off is a sudden 50x surge. Debugging gets harder: a user's bad response may come from a PoP you cannot see. Purge is eventually consistent, so content changes are seconds behind. Personalised or private responses mostly cannot be cached at the edge, and getting the cache key wrong there is a data leak.
In an interview
Put the CDN in front of anything static the moment you draw the diagram, and say the TTL. Then go one level deeper: versioned asset names with long TTLs, stale-while-revalidate for pages, an origin shield if you have many PoPs, and a plan for purge. If the problem has a global audience and large media (video, images), the CDN is a core component, not a decoration; talk about segment caching and byte-range requests.
Check yourself
You need a CSS change to be visible to every user worldwide within seconds, and the file is cached at the edge for a year. What is the reliable approach?