Chapter 12 — CDN & Content Delivery
Chapter 12 — CDN & Content Delivery
Hey everyone! Welcome back to Namaste System Design! 🙏
Your server lives in Virginia. A user in Mumbai clicks play on a video. The data has to cross oceans — that's ~200ms of latency before anything even happens, plus a huge load on your one server if millions do it. The fix is one of the most impactful tools in web performance: the CDN. Remember the latency ladder from Chapter 03 — distance is expensive. A CDN kills the distance.
What we will cover:
- What a CDN is (the local warehouse analogy)
- Edge servers / PoPs
- Static vs dynamic content
- Push vs pull CDNs
- Cache-Control, TTL, and invalidation
- What a CDN actually buys you
- Interview Questions
1. The Local Warehouse Analogy
Amazon doesn't ship every order from one warehouse in the US. It keeps local warehouses near you, stocked with popular items, so delivery is fast. A CDN does exactly this — for your website's files. 📦
┌─────────────────────────────────────────────────────────────┐
│ CDN (Content Delivery Network) = a global network of │
│ servers ("edge servers") that keep COPIES of your │
│ content physically close to users. │
│ │
│ Instead of every user reaching your ONE origin server, │
│ they hit the NEAREST edge — fast, and it offloads │
│ your origin. │
└─────────────────────────────────────────────────────────────┘
WITHOUT CDN: WITH CDN: Mumbai user ──✈✈✈──▶ Origin Mumbai user ─▶ Mumbai edge ⚡ (200ms, crosses ocean) (10ms, next door) ALL users hammer origin 🔥 Origin barely touched 😌
Providers: Cloudflare, Akamai, AWS CloudFront, Fastly.
2. Edge Servers & PoPs
Your ORIGIN server (the source of truth)
│ content pushed/pulled to edges
┌──────────┼──────────┬──────────┬──────────┐
▼ ▼ ▼ ▼ ▼
[Mumbai] [Tokyo] [London] [NYC] [Sydney] ← EDGE servers
▲ ▲ ▲ ▲ ▲ (aka PoPs:
nearby nearby nearby nearby nearby Points of
users users users users users Presence)
A user is automatically routed to their nearest PoP.
3. What Goes on a CDN? Static vs Dynamic
| Static content ✅ great for CDN | Dynamic content ⚠️ trickier | |
|---|---|---|
| Examples | Images, videos, CSS, JS, fonts, PDFs | Personalized feed, account balance |
| Changes? | Rarely — same for everyone | Different per user, per request |
| Cacheable? | Yes — cache it everywhere | Hard — but "edge compute" is closing the gap |
Classic move: serve all static assets (the bulk of most sites — images and video are huge) from the CDN, and route only the small dynamic API calls to your origin. This alone can offload 80–90% of traffic.
4. Push vs Pull CDNs
┌─────────────────────────────────────────────────────────────┐ │ PULL CDN (most common): │ │ Edge is empty at first. On the FIRST user request, the │ │ edge PULLS the file from origin, caches it, then serves │ │ all future users from cache. Lazy, self-managing. │ │ │ │ PUSH CDN: │ │ YOU upload files to the CDN ahead of time. You control │ │ what's there. Good for large files that rarely change │ │ (e.g. a big software download). │ └─────────────────────────────────────────────────────────────┘
PULL (first request is a miss, rest are hits): User 1 → edge (MISS) → pulls from origin → caches → serves User 2 → edge (HIT ⚡) → served instantly, origin untouched
5. Freshness: TTL & Invalidation
Same problem as any cache (Chapter 06): the CDN holds copies that can go stale. Controlled by HTTP headers:
Cache-Control: max-age=86400 → "keep this for 24 hours" TTL expires → edge re-fetches fresh copy from origin. Need to update NOW (e.g. you pushed a bug fix in app.js)? → PURGE / INVALIDATE the file so edges re-fetch immediately. PRO TRICK — cache busting: Rename the file on each deploy: app.v2.js, app.a1b2c3.js → a new name = a guaranteed fresh fetch, no purge needed.
6. What a CDN Buys You
✅ LOW LATENCY → content is physically near the user ✅ LESS ORIGIN → most requests never reach your server LOAD (huge cost + capacity savings) ✅ HIGH → CDN absorbs traffic spikes & has huge capacity AVAILABILITY ✅ DDoS SHIELD → CDNs absorb/filter attack traffic at the edge ✅ BANDWIDTH → serving from edge is cheaper than from origin SAVINGS
Interview Questions — Quick Fire!
Q: What is a CDN and why do we use it?
"A CDN is a globally distributed network of edge servers that cache copies of your content close to users. We use it to reduce latency — users fetch from a nearby edge instead of a distant origin — and to offload the origin server, since most requests are served from the edge. It also improves availability, absorbs traffic spikes, and helps mitigate DDoS attacks."
Q: What kind of content is best served from a CDN?
"Static content that's the same for everyone and changes rarely — images, videos, CSS, JavaScript, fonts. That's the bulk of most sites' bandwidth. Dynamic, personalized content is harder to cache because it differs per user, so typically you serve static assets from the CDN and route dynamic API calls to the origin, though edge computing is increasingly handling dynamic content too."
Q: What's the difference between a push and a pull CDN?
"With a pull CDN, the edge starts empty and lazily pulls a file from the origin on the first request, then caches it for subsequent users — it's self-managing and most common. With a push CDN, you proactively upload content to the CDN ahead of time and control exactly what's stored, which suits large files that change rarely."
Q: How do you handle stale content on a CDN?
"Through TTL via Cache-Control headers — content expires after a set time and the edge re-fetches a fresh copy. For immediate updates you can purge or invalidate specific files so edges re-fetch them. A common trick is cache busting: renaming files with a version or hash on each deploy, so a new filename guarantees a fresh fetch without needing to purge."
Key Points to Remember
| Concept | Key Takeaway |
|---|---|
| CDN | Global edge servers caching content near users → low latency + origin offload. |
| Edge/PoP | Users routed to nearest Point of Presence. |
| Static vs dynamic | Static (images, JS, video) is ideal; dynamic is harder to cache. |
| Push vs pull | Pull = lazy, self-managing (common) · Push = you pre-upload. |
| Freshness | TTL + purge/invalidate + cache busting (versioned filenames). |
What's Next?
Chapter 13 closes Season 3 with rate limiting — how a system protects itself from abuse, bots, and accidental floods by capping how many requests any one client can make. We'll meet the token bucket and its cousins.
Keep designing, keep scaling! See you in the next one!
Post a Comment