System design · interactive
CDNs: caching at the edge
Your origin server is in Virginia. Users in Karachi, London and New York each load your logo once per tick. Put a CDN in front, choose how long edges may keep a copy, then ship a new logo and see who still gets the old one.
Karachi edge
MISS · 252 ms · v1 until t10
London edge
MISS · 95 ms · v1 until t10
New York edge
MISS · 23 ms · v1 until t10
Origin (Virginia)
logo v1 · 3 requests
H hit · M miss (went to origin) · red = old logo after the deploy · ▼ new logo ships
Tick 0: 3 edges had to go to the origin.
Cache-Control max-age (TTL)
When the new logo ships (tick 6)
Do nothing. Each edge refetches when its copy expires.
- hit ratio
- 0%
- origin requests
- 3
- stale logos
- 0
1 2 3 The edge fetches from Virginia, stores the copy for max-age, and returns it. Far-away users pay the full round trip.
Karachi +240 ms · London +85 ms · New York +15 ms
4 5
In production
Tools and technologies
Every CDN works the same way: edges near users, a cache with a TTL, and a way to purge.
Not tied to one language — use these names when you search docs or design a system.
- Cloudflare CDNService
Reverse-proxy CDN in hundreds of cities; purge by URL, tag or everything.
Official site ↗ - Amazon CloudFrontService
AWS's CDN with invalidations and cache policies.
Official site ↗ - FastlyService
Programmable edge cache with near-instant purge.
Official site ↗ - Varnish CacheSoftware
The open-source HTTP cache many CDNs grew from.
GitHub ↗ - HTTP Cache-ControlStandard
max-age, s-maxage and immutable decide how long edges keep a copy.
Documentation ↗