CDNs & the edge
Your server is in Virginia; your user is in Tokyo. The speed of light alone adds 150ms+.
Open the interactive version → diagrams, practice & moreThe problem
Your server is in Virginia; your user is in Tokyo. The speed of light alone adds 150ms+.
The idea
A CDN caches content at edge locations physically near users worldwide.
How it works
A CDN caches content at edge POPs near users; a miss climbs a hierarchy (edge → regional shield → origin) so the origin sees a tiny fraction of traffic. The cache key (URL + chosen headers) decides hit ratio — fold in too much (cookies, volatile headers) and you fragment the cache to near-zero hits. Invalidation is the hard part: explicit purge is slow and global, so teams prefer versioned/fingerprinted URLs (app.a1b2.js) that are immutable and cache forever.
The tradeoff
Great for static and cacheable content; dynamic, personalized, write-heavy traffic still reaches origin (edge compute narrows that gap). A bad cache key or a Vary on volatile headers tanks the hit ratio. Purge-based invalidation is operationally painful and eventually-consistent across POPs — versioned URLs sidestep it entirely.
In the wild
Cloudflare, Akamai, CloudFront. Netflix serves video from edge caches inside ISPs.
Interview deep dive
Flow
- Serve static/cacheable assets from the nearest edge POP.
- On miss, climb edge → regional shield → origin.
- Tune the cache key and Cache-Control to maximize hit ratio.
- Invalidate via versioned URLs; reserve purge for emergencies.
Watch for
- Cookies/volatile headers in the cache key shred the hit ratio.
- Purge is slow and eventually-consistent across POPs.
- Personalized/dynamic responses bypass the edge — keep them thin.
Interviewer trap
Talk cache-key design and versioned-URL invalidation, not just "add a CDN".