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, and what the origin still does
- Static vs dynamic content
- Push vs pull CDNs — worked example
- Cache hit vs cache miss — the request flow, with real latency numbers
- TTL, invalidation, and cache busting
- 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 & the Origin
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
(DNS or Anycast routing picks it for them, no client code needed).
Who does what:
ORIGIN → the one true copy. Handles writes, dynamic
logic, and anything that isn't cached.
EDGE / PoP → hundreds of these worldwide. Holds COPIES
of popular content, and answers almost all
the READ traffic on the origin's behalf.
The origin should rarely hear from users directly — only
from edges that don't have what they need yet.
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. How Content Gets Cached — and Kept Fresh
Now the mechanics: how does a file end up on an edge, and how does the edge know when to throw its copy away?
4.1 Push vs Pull CDNs
Two different ways content ends up on the edge.
PULL CDN (most common): Edge starts EMPTY. First request for a file is a MISS — the edge fetches it from origin, caches it, then serves every future request from cache. Lazy, self-managing. PUSH CDN: YOU upload files to the CDN ahead of time. Nothing is fetched lazily — you control exactly what's there.
✅ PULL Zero setup, scales to any number of files, only
caches what's actually requested.
👉 USE IT WHEN General web assets — you don't know in
advance what will be popular.
✅ PUSH You control timing exactly — nothing is ever a
surprise cold miss for a real user.
👉 USE IT WHEN A few large files that rarely change, e.g.
a big software installer or a game patch.
4.2 Cache Hit vs Cache Miss — the real numbers
This is the whole game. A hit is fast. A miss pays the full round trip once — and never again.
Request 1 — MISS (edge is empty, first time anyone asked):
Mumbai user ─▶ Mumbai edge (2ms) ─▶ MISS
│
▼ fetch from origin, Virginia (180ms RTT)
Origin responds ─▶ edge CACHES it
│
edge ─▶ user TOTAL: ~185ms
Request 2 — HIT (next user, same file):
Mumbai user ─▶ Mumbai edge (2ms) ─▶ HIT ⚡ ─▶ user
TOTAL: ~12ms
Same file. ~15x faster on a hit. And the ORIGIN never
even heard about request 2 — it was served entirely
from the edge.
4.3 TTL — how long a copy stays "fresh"
Cache-Control: max-age=86400 → "keep this for 24 hours"
t = 0h file cached at the edge, marked fresh
t = 24h TTL expires → file is now "stale"
next request after t=24h → edge re-fetches from origin,
caches the new copy, resets TTL
Short TTL → fresher content, more origin traffic
Long TTL → less origin traffic, staler content
It's a dial, not a fixed rule — tune it per content type.
4.4 Invalidation & Cache Busting
Need to update NOW (e.g. you shipped a bug fix in app.js), can't wait for the TTL to expire? OPTION 1 — PURGE / INVALIDATE: Tell the CDN "throw away app.js everywhere" right now. Next request is a guaranteed MISS → fetches the new file. OPTION 2 — CACHE BUSTING (the pro move): Rename the file on every deploy: app.js → app.a1b2c3.js A new name IS a new URL → automatically a fresh fetch. No purge needed, and old cached copies just expire quietly.
Visual Comparison
| Push CDN | Pull CDN | |
|---|---|---|
| Setup effort | ❌ You upload manually | ✅ None — lazy on first request |
| First request | ✅ Always a hit (pre-loaded) | ❌ Guaranteed miss (cold) |
| Good for many small/changing files | ❌ | ✅ |
| Good for a few large stable files | ✅ | ❌ (wastes bandwidth re-checking) |
What Do Big Companies Actually Use?
Cloudflare, Fastly, AWS CloudFront
Pull-based by default for general web traffic;
all support push/pre-warming for special cases.
Akamai One of the oldest and largest edge networks —
heavily used for video and large software delivery.
Game & software downloads (patches, installers)
Often PUSH — publishers pre-stage the build to
edges before announcing a release, so launch-day
traffic never causes a cold-miss stampede on origin.
Interview-safe default: "Most content should go through a pull CDN — it's zero-config and self-managing. I'd reach for push only for large, rarely-changing files where I want to guarantee there's never a cold miss for a real user, like a big client-facing release."
5. 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, like a big software release you want pre-staged before launch."
Q: Walk me through what happens on a cache miss vs a cache hit.
"On a miss, the edge doesn't have the file, so it forwards the request to the origin, waits for the full round trip — which can be well over 100ms across a continent — caches the response, then returns it. On a hit, the edge already has the file and returns it directly, often in under 15ms, without the origin being involved at all. That's why the very first user to request a file pays the full cost, but everyone after them gets it fast."
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/Origin | Users hit the nearest PoP; origin is the source of truth and handles the rest. |
| 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, no cold miss. |
| Hit vs miss | Miss pays the full origin round trip once; every hit after is ~10x+ faster. |
| 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