What it is
A CDN is a geographically distributed network of edge servers that caches content close to users. It attacks the one latency you cannot engineer away — distance. Light in fibre covers roughly 100 km per millisecond one way, so New York to London has an ~80 ms floor no matter how good the code is; an edge cache 20 km from the user answers in 10–50 ms.
In interviews the CDN is mandatory in any media or global design (YouTube, Instagram, news feed assets), and the real test is whether I cleanly separate the static path from the dynamic path. Images, video segments and JS bundles go through the CDN and never touch my app servers; personalised API responses mostly don't. Getting that split right is worth more than knowing any vendor's feature list.
All media and static assets go through a pull CDN with versioned URLs so I never purge — the origin only ever serves each object once per region, and my app servers never touch a byte of video.
The picture
The variants and when to pick each
Pull CDN — the right default
The edge fetches from origin on the first miss in each region, caches the object with a TTL, and serves every subsequent request locally. Nothing to pre-provision, storage is spent only on what users actually request, and it degrades gracefully — a cold edge is a slow request, not an outage.
The cost is the first user per region eats the origin round trip, and origin must survive a burst of regional misses after a purge. For most sites this is the answer; say it and move on.
Push CDN — for big, predictable releases
I upload content to the edge ahead of demand: a film release, a game patch, tomorrow's app bundle. No cold-start misses anywhere, and origin sees no thundering herd at launch.
Now I own the lifecycle — deciding what's on which edge, when it expires, and paying for storage on content that may never be watched in some regions. This is Netflix's model with Open Connect boxes inside ISPs, pushing 95%+ of their traffic from the edge.
Invalidation: versioned URLs beat purging
The strongest pattern is to never invalidate: put a content hash in the filename (app.3f9a2c.js), serve it with max-age=31536000, immutable, and every deploy simply references new URLs. Old versions age out untouched; there is no purge race, no stale-cache incident, no waiting on a purge API to propagate to 300 edges.
For content whose URL must stay stable (a user's avatar at a fixed path), fall back to short TTLs or the purge API — and accept purges are eventually consistent across the edge fleet.
Caching dynamic content — further than people think
CDNs are not only for files. Shared, non-personalised API responses — trending lists, public profiles, search results for common queries — can sit at the edge with a 30–60 second TTL and correct cache-control and vary headers, absorbing enormous read load for data where slight staleness is fine.
Edge compute (Cloudflare Workers, Lambda@Edge) goes further: auth checks, A/B assignment and light personalisation run at the edge over cached data. In a video design, the thing being cached is not "the file" — it's transcoded HLS/DASH segments per bitrate, which is the door into adaptive streaming.
Numbers worth memorising
| Edge hit latency | ~10–50 ms vs ~150–300 ms cross-continent origin |
| Speed of light in fibre | ~100 km per ms one way — NY→London ≈ 80 ms RTT floor |
| CDN offload for media sites | 90%+ of bytes served from edge |
| 1 hour of 1080p video | ~3 GB — why video without a CDN is a non-starter |
| Immutable asset TTL | max-age=31536000 (1 year) with hashed URLs |
Where the interviewer pushes
The first push is invalidation: "the file changed — how do users see the new one?" The strong answer leads with versioned URLs — a new deploy references new hashed filenames, so nothing ever needs purging and old assets die of TTL. Then acknowledge the residual case: stable URLs that must update in place get short TTLs or an explicit purge, and purges propagate eventually, so there's a stale window I have to be able to tolerate.
The second push is "can you CDN-cache API responses, or only static files?" Yes — for shared, non-personalised data with a short TTL and correct vary headers, and it's often the cheapest read-scaling step available. The line I draw out loud: anything personalised or authenticated skips shared cache (or gets private), because a vary mistake that serves one user's data to another is a security incident, not a staleness bug.