CDN / Edge

SYSTEM DESIGN SERIES  ·  TOPIC 08 OF 23+  ·  part of the 07 → 08 → 09 chain
1. What a CDN Actually Is
A network of caching servers, spread close to wherever users are
  • A globally distributed network of caching servers ("PoPs")
  • Sits between users and your origin server
  • Serves a cached copy from the PoP closest to the user
  • Directly cuts the network latency topic 01 was about
  • Offloads traffic so the origin never sees most of it (topic 03)
2. Why It Works - Distance Is the Enemy
Light through fiber has a speed limit - this is physics, not a bug
  • Light in fiber travels at ~200,000 km/s, not instantly
  • Mumbai → Virginia and back pays that round-trip tax on every request
  • A nearby edge server erases most of that physical distance
  • This is topic 01's latency lesson, solved geographically
3. Origin Pull vs Origin Push
Origin Pull (Lazy)
  • Edge fetches from origin on first request
  • Same idea as cache-aside (topic 07), geographically
  • First user at each PoP eats a cache miss
VS
Origin Push (Proactive)
  • Content is uploaded to every edge node upfront
  • Guarantees availability everywhere, immediately
  • Wastes space on content nobody there requests
📚 Analogy: Pull is a library that special-orders a book only when someone asks. Push is stocking every branch with every book, whether anyone reads it there or not.
4. What Actually Gets Cached at the Edge
Static was the start - edge compute changed the game
  • Static assets - images, video, CSS, JS: classic, rarely change
  • Cacheable API responses - fine if not personalized (topic 07's rules still apply)
  • Edge compute - actual logic running at the PoP (Workers, Lambda@Edge), not just files
  • Cache-Control / Expires headers - how the origin tells the edge how long to hold it
🎬 Video streaming is the extreme case: huge files, massive reuse, near-zero personalization - the ideal CDN workload.
5. Routing Users to the Nearest Edge
How does a request even find the closest PoP?
  • Anycast - the same IP is announced from many locations; the network itself routes to the nearest one
  • GeoDNS - DNS resolves to a different IP depending on where the request came from
  • Latency-based routing - some CDNs actively measure and route to the fastest PoP, not just the nearest
🌐 "Nearest" and "fastest" aren't always the same PoP - real-world routes and congestion don't follow straight lines on a map.
6. The Cost of Being Everywhere
Distributing the cache also distributes the headaches
Purge Must Reach Every PoP
Staleness Risk
$ Cost of Many PoPs
Doesn't Help Writes
Doesn't Help Personalization
One origin update now has to reach hundreds of caches, not one
Purging one Redis key (topic 07) is easy. Purging a file from 300 PoPs worldwide, correctly and fast, is its own engineering problem.
7. When a CDN Helps - and When It Doesn't
Great fit:
✔ Static assets - images, CSS, JS, fonts
✔ Video and large file delivery
✔ Read-heavy public content
✔ A genuinely global user base
Cache Where the User Is, Not Just Where the Data Is
Poor fit:
✘ Write-heavy APIs
✘ Highly personalized responses
✘ Real-time, bidirectional data
✘ Anything that must read the latest write
💡 Reads just got fast and cheap. Now: what does a write actually cost? That's topic 09.