Episode 9 — System Design / 9.9 — Core Infrastructure
9.9.b CDN and Content Delivery
What CDNs Do
A Content Delivery Network (CDN) is a geographically distributed network of servers that caches and serves content from locations close to users. The goal: reduce latency, offload origin servers, and improve availability.
WITHOUT CDN:
User (Sydney) -------- 200ms --------> Origin (US-East)
User (London) -------- 150ms --------> Origin (US-East)
User (Tokyo) -------- 180ms --------> Origin (US-East)
All requests travel the full distance to origin.
WITH CDN:
User (Sydney) --- 10ms ---> CDN Edge (Sydney) --- Cache HIT
User (London) --- 8ms ---> CDN Edge (London) --- Cache HIT
User (Tokyo) --- 5ms ---> CDN Edge (Tokyo) --- Cache HIT
Content served from nearby edge. Origin is rarely contacted.
What a CDN Stores
| Content Type | Examples | Cacheability |
|---|---|---|
| Static assets | Images, CSS, JS, fonts, videos | Highly cacheable |
| HTML pages | Landing pages, blog posts | Cacheable with care |
| API responses | Product listings, search results | Cacheable if idempotent |
| Live streams | Video chunks (HLS/DASH) | Short TTL caching |
| Downloads | Software installers, PDFs | Highly cacheable |
Push vs Pull CDN
Pull CDN (Origin Pull)
The CDN fetches content from the origin on demand when a user requests it.
Pull CDN Flow:
User --> CDN Edge
|
|--> Cache HIT? --> Serve cached content
|
|--> Cache MISS?
| |
| +--> Fetch from Origin Server
| +--> Cache the response
| +--> Serve to user
|
Subsequent requests for same content --> Cache HIT
Characteristics:
- Content is cached lazily (only when requested)
- First request to each edge has higher latency (origin fetch)
- Origin must be available for cache misses
- Cache naturally expires via TTL
Best for: Most use cases. Websites, APIs, media sites.
Push CDN
Content is pre-uploaded to all CDN edge locations before users request it.
Push CDN Flow:
Admin/CI Pipeline --> Upload to CDN --> Replicated to all edges
Edge (Tokyo): [file.js, image.png, video.mp4]
Edge (London): [file.js, image.png, video.mp4]
Edge (Sydney): [file.js, image.png, video.mp4]
User --> CDN Edge --> Always a Cache HIT (content pre-loaded)
Characteristics:
- No cache miss penalty (content is pre-loaded)
- You control exactly what is cached and when
- Requires more storage (content on every edge)
- Manual management of content lifecycle
Best for: Known static content, software releases, large media files.
Comparison Table
| Aspect | Pull CDN | Push CDN |
|---|---|---|
| Content loading | On demand | Pre-uploaded |
| First request | Cache miss (slow) | Cache hit (fast) |
| Storage cost | Lower (only popular content cached) | Higher (everything replicated) |
| Management | Automatic | Manual upload required |
| Origin load | Higher (serves cache misses) | Lower (rarely contacted) |
| Best for | Dynamic traffic patterns | Known, predictable content |
| Examples | CloudFront (default), Cloudflare | S3 + CloudFront, Akamai NetStorage |
Edge Locations and PoPs
A Point of Presence (PoP) is a physical location where CDN servers reside. Each PoP contains multiple edge servers.
Global CDN Topology:
+----------+ +----------+ +----------+
| PoP: | | PoP: | | PoP: |
| New York | | London | | Tokyo |
| [E1][E2] | | [E1][E2] | | [E1][E2] |
| [E3][E4] | | [E3][E4] | | [E3][E4] |
+-----+----+ +-----+----+ +-----+----+
| | |
+-------+--------+--------+-------+
| |
+----+----+ +----+----+
| Origin | | Origin |
| US-East | | US-West |
+---------+ +---------+
How users reach the nearest edge:
- DNS-based routing: CDN DNS returns the IP of the nearest edge
- Anycast: Multiple edges share the same IP; BGP routes to the closest
- GeoDNS: DNS resolves based on the user's geographic location
User in Tokyo types: cdn.example.com
DNS Lookup:
cdn.example.com --> CDN DNS --> "User is in Asia-Pacific"
--> Return IP of Tokyo PoP
User connects to Tokyo PoP --> Content served locally
Cache Headers and CDN Behavior
HTTP cache headers control how CDNs cache and serve content.
Cache-Control Header
Cache-Control: public, max-age=86400, s-maxage=31536000
| Directive | Meaning |
|---|---|
public | Any cache (CDN, browser) can store this |
private | Only browser can cache; CDN must not |
max-age=N | Browser cache for N seconds |
s-maxage=N | CDN (shared cache) caches for N seconds (overrides max-age) |
no-cache | Must revalidate with origin before serving |
no-store | Do not cache at all |
immutable | Content will never change; no revalidation needed |
stale-while-revalidate=N | Serve stale for N seconds while fetching fresh copy |
Common Caching Strategies
Static assets (CSS, JS, images):
Cache-Control: public, max-age=31536000, immutable
Cache for 1 year. Use versioned URLs (e.g., app.abc123.js) to bust cache.
HTML pages:
Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=60
CDN caches for 5 minutes. Browser always revalidates. Serve stale for 60s during refresh.
API responses:
Cache-Control: public, max-age=60, s-maxage=300
Vary: Authorization, Accept-Encoding
CDN caches for 5 minutes, browser for 1 minute. Separate caches per auth token.
Personalized content:
Cache-Control: private, no-store
Never cache on CDN. Each user sees different content.
ETag and Conditional Requests
First Request:
Client --> CDN --> Origin
Origin --> 200 OK
ETag: "abc123"
Body: <full content>
CDN caches response with ETag.
Subsequent Request (after TTL expires):
Client --> CDN --> Origin
If-None-Match: "abc123"
Origin --> 304 Not Modified (no body)
CDN serves cached version, resets TTL.
(Saves bandwidth -- no body transferred)
Static vs Dynamic Content at the CDN
Static Content
- Images, videos, CSS, JavaScript, fonts, documents
- Identical for every user
- Perfect for CDN caching (long TTL, high hit rate)
Dynamic Content
- Personalized pages, real-time data, search results
- Varies per user, request, or time
- Can still be cached with care:
Dynamic Content Caching Strategies:
1. Edge-Side Includes (ESI):
+----------------------------------+
| Page Layout (cached) |
| +----------------------------+ |
| | User Greeting (dynamic) | |
| +----------------------------+ |
| +----------------------------+ |
| | Product List (cached 5min) | |
| +----------------------------+ |
| +----------------------------+ |
| | Cart Widget (dynamic) | |
| +----------------------------+ |
+----------------------------------+
2. API Response Caching:
/api/products?category=shoes --> Cache 5 min
/api/user/profile --> Never cache on CDN
3. Edge Compute (Cloudflare Workers, Lambda@Edge):
Run custom logic at the edge to personalize
cached content without hitting origin.
CDN Providers Comparison
| Feature | CloudFront (AWS) | Cloudflare | Akamai | Fastly |
|---|---|---|---|---|
| Edge locations | 450+ PoPs | 310+ cities | 4,000+ servers | 80+ PoPs |
| DDoS protection | AWS Shield | Built-in (excellent) | Prolexic | Built-in |
| Edge compute | Lambda@Edge, CloudFront Functions | Workers | EdgeWorkers | Compute@Edge (Wasm) |
| SSL/TLS | ACM integration | Free universal SSL | Custom | Custom |
| Pricing model | Pay per request + transfer | Free tier + plans | Enterprise pricing | Pay per request |
| Best for | AWS-heavy architectures | General purpose, security | Enterprise, media | Real-time, API caching |
| Purge speed | Seconds | ~30 seconds global | Seconds | Instant (150ms) |
| WebSocket support | Yes | Yes | Yes | Yes |
CDN in System Design Interviews
When to Mention CDN
Always mention CDN when the system involves:
- Serving static content (images, videos, files)
- Global user base (latency matters)
- High read-to-write ratio
- Reducing origin server load
- DDoS protection needs
How to Draw CDN in Architecture Diagrams
Correct placement:
Users --> DNS --> CDN Edge --> [Cache HIT: serve]
|
+--> [Cache MISS: fetch from origin]
|
Load Balancer
|
App Servers
|
Database
CDN Interview Talking Points
- "We will place a CDN in front of our static assets to reduce latency for global users."
- "For API responses that are read-heavy and not user-specific, we can cache at the CDN with a short TTL."
- "We will use cache headers to control TTL and versioned URLs for cache busting."
- "The CDN also provides DDoS protection as an added benefit."
When NOT to Use a CDN
| Scenario | Why CDN Hurts |
|---|---|
| All users in one region | Adds complexity without latency benefit |
| Highly personalized content | Low cache hit rate, wasted edge storage |
| Real-time data (live prices) | Stale data is unacceptable |
| Small, internal tool | Overkill; adds cost and complexity |
| Sensitive data | Data residency concerns; edge locations in many countries |
CDN Cache Invalidation
When content changes, you need to remove stale entries from CDN edges.
Methods
1. Purge (Instant Invalidation)
# CloudFront
aws cloudfront create-invalidation \
--distribution-id E1234 \
--paths "/images/*" "/css/*"
# Cloudflare
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone}/purge_cache" \
-d '{"files":["https://example.com/style.css"]}'
2. Versioned URLs (Recommended)
OLD: /static/app.js
NEW: /static/app.v2.js (or /static/app.abc123.js)
Old version naturally expires. New version is a fresh cache entry.
No purge needed!
3. Cache Tags (Surrogate Keys)
Response Header: Surrogate-Key: product-123 category-shoes
Purge by tag:
"Purge all content tagged product-123"
--> All edges remove matching entries
End-to-End CDN Architecture Example
E-Commerce Platform CDN Setup:
+-------------------------------------------------------------+
| |
| Browser |
| | |
| +--> static.example.com --> CDN (images, CSS, JS) |
| | Cache-Control: public, max-age=31536000, immutable |
| | |
| +--> api.example.com --> CDN --> API Gateway --> Services |
| | Cache-Control: public, s-maxage=60 |
| | Vary: Accept-Encoding |
| | |
| +--> www.example.com --> CDN --> Web Servers |
| Cache-Control: public, s-maxage=300, |
| stale-while-revalidate=60 |
| |
| Origin: |
| S3 Bucket (static assets) |
| API Servers (dynamic responses) |
| Web Servers (HTML rendering) |
+-------------------------------------------------------------+
Key Takeaways
- CDNs reduce latency by serving content from edge locations near users
- Pull CDNs are simpler and more common; push CDNs give more control
- Cache headers are your primary tool for controlling CDN behavior
- Versioned URLs are the cleanest cache invalidation strategy
- CDN is not just for static content -- API responses and HTML can be cached too
- Edge compute (Workers, Lambda@Edge) enables dynamic logic without origin round-trips
- Always mention CDN in system design interviews for read-heavy, global systems
- CDN also provides DDoS protection and reduces origin server load
Explain-It Challenge
"You are designing a news website that gets 10 million daily visitors across 30 countries. Breaking news articles must appear within 30 seconds of publishing, while older articles and images should be served as fast as possible. Explain your CDN strategy, including cache headers, invalidation approach, and how you handle the transition from dynamic (just published) to static (hours old) content."