Content Delivery Network (CDN)
A Content Delivery Network (CDN) is a geographically distributed system of proxy servers that caches and delivers content from locations closer to users. In system design interviews, CDNs appear whenever you're designing systems that serve static content globally—they're how Netflix streams video, how websites load images instantly, and how applications achieve sub-100ms response times worldwide.
This page covers what you need to know for interviews: why CDNs matter, how they work, push vs pull models, cache consistency strategies, and how to route users to the nearest edge server. Understanding these concepts helps you design systems that serve millions of users with low latency regardless of their geographic location.
Why CDNs Matter
Without a CDN, every user request travels to your origin server, regardless of where the user is located. A user in Tokyo requesting content from a server in Virginia experiences ~200ms round-trip latency just from the speed of light—before any server processing.
Key benefits of using a CDN:
- Reduced latency — Content served from edge servers 10-50ms away instead of 100-300ms
- Reduced origin load — Edge servers handle most requests, origin only serves cache misses
- Improved availability — If origin goes down, cached content remains available
- DDoS protection — Distributed infrastructure absorbs traffic spikes and attacks
- Bandwidth savings — Origin sends content once to CDN, CDN serves it to millions
In interviews, don't spend time explaining that you need a CDN—interviewers expect it for any globally-distributed system. Focus on what content to cache, how to handle cache invalidation, and which CDN model (push vs pull) fits your use case. That's where the interesting discussion happens.
How CDNs Work
A CDN consists of edge servers (also called proxy servers or Points of Presence/PoPs) distributed across many geographic locations. When a user requests content, the CDN routes them to the nearest edge server. If that server has the content cached, it serves it directly. If not, it fetches from the origin, caches it, and then serves the user.
CDN Components
| Component | Purpose |
|---|---|
| Edge/Proxy servers | Cache and serve content to users from RAM/SSD |
| Origin servers | Store the authoritative version of all content |
| Routing system | Directs users to the optimal edge server |
| Distribution system | Pushes content from origin to edge servers |
| Management system | Monitors health, performance, and accounting |
Request Flow
- User requests
cdn.example.com/image.png - DNS resolves to the IP of the nearest edge server (via DNS-based routing or anycast)
- Edge server checks its cache for
image.png - Cache hit: Return content immediately (~10-50ms total)
- Cache miss: Fetch from origin, cache locally, then return to user
Push vs Pull CDN Models
CDNs use two approaches to get content from origin servers to edge servers. Understanding when to use each is important for interviews.
Pull CDN (Origin Pull)
Edge servers fetch content from origin on-demand when users request it. Content is cached after the first request and served from cache for subsequent requests until TTL expires.
Characteristics:
- Edge only stores content that's actually requested
- First user experiences slower response (cache miss)
- Lower storage costs—unpopular content not cached
- Simpler to set up—no explicit push required
Best for: Dynamic content, long-tail content (many items with few requests each), unpredictable access patterns.
Push CDN
Origin server proactively pushes content to edge servers before users request it. Content provider decides what to distribute and when.
Characteristics:
- Content available immediately when users request it (no cold cache)
- Higher storage costs—content pushed even if never requested
- More control over what's cached where
- Requires explicit push when content changes
Best for: Static content, popular content, content where first-request latency matters (breaking news, product launches).
Comparison
| Aspect | Pull CDN | Push CDN |
|---|---|---|
| First request | Slow (cache miss) | Fast (pre-cached) |
| Storage efficiency | High (only requested content) | Lower (all pushed content) |
| Setup complexity | Simple | More complex |
| Content freshness | Controlled by TTL | Controlled by push timing |
| Best for | Dynamic, long-tail | Static, popular content |
Interview default: Most CDNs use pull model by default—it's simpler and handles the common case well. Mention push model when discussing scenarios like "We'd pre-warm the cache with push for major launches to avoid thundering herd on the first request." Real CDNs often use both: push for popular content, pull for everything else.
Static vs Dynamic Content
Understanding what types of content CDNs can accelerate helps you make better design decisions.
Static Content
Content that doesn't change between users or requests:
- Images, videos, audio files
- CSS, JavaScript bundles
- Fonts, icons
- PDF documents
CDN strategy: Long TTLs (hours to days), aggressive caching, content-based URLs for cache busting (e.g., style.a1b2c3.css).
Dynamic Content
Content that varies by user, time, or request parameters:
- Personalized recommendations
- User-specific data
- Real-time prices, inventory
- API responses
CDN strategy: Short TTLs or no caching, Edge-Side Includes (ESI) to cache static portions, edge computing for personalization.
Edge-Side Includes (ESI)
ESI allows caching parts of a page while keeping other parts dynamic. The edge server assembles the final page from cached and dynamic fragments.
<!-- Cached page template -->
<html>
<header><!-- cached header --></header>
<esi:include src="/api/user-greeting" /> <!-- fetched dynamically -->
<main><!-- cached main content --></main>
</html>
This technique lets you cache 90% of a page while still personalizing greetings, recommendations, or prices.
In interviews, when discussing dynamic content: "For the product catalog, we'd cache the page structure with a 1-hour TTL and use ESI to inject personalized recommendations. The CDN assembles the page at the edge, so users get fast responses while still seeing personalized content."
Cache Consistency
Keeping edge server caches synchronized with the origin is one of the hardest problems in CDN design. Several strategies exist, each with trade-offs.
Time-To-Live (TTL)
Each cached object has an expiration time. After TTL expires, the edge server revalidates with origin before serving.
Cache-Control: max-age=3600 # Cache for 1 hour
Cache-Control: s-maxage=86400 # CDN caches for 24 hours
Trade-off: Short TTL = fresher content but more origin load. Long TTL = better performance but staler content.
| Content Type | Typical TTL | Reasoning |
|---|---|---|
Versioned assets (app.v2.js) | 1 year | URL changes when content changes |
| Images | 24 hours - 7 days | Rarely change |
| API responses | 1-60 minutes | Balance freshness and performance |
| User-specific data | 0 (no cache) | Must be fresh |
Cache Invalidation
Explicitly remove or update cached content before TTL expires.
Purge: Remove specific URLs from all edge caches
POST /purge
{ "urls": ["https://cdn.example.com/image.png"] }
Soft purge: Mark as stale, serve stale while revalidating in background
Tag-based invalidation: Purge all content with a specific tag
POST /purge
{ "tags": ["product-123"] }
Versioned URLs
Instead of invalidating, change the URL when content changes. Old content naturally expires, new content is fetched fresh.
Before: /styles.css
After: /styles.a1b2c3d4.css # Hash of content in filename
Pros: No invalidation needed, perfect cache hit ratio for unchanged content Cons: Requires build system to generate hashes, HTML must reference new URLs
Cache invalidation is notoriously difficult. In interviews, acknowledge this: "We'd use versioned URLs for static assets to avoid invalidation entirely. For API responses, we'd use short TTLs with stale-while-revalidate so users get fast responses while we update the cache in the background."
Routing Users to Edge Servers
A CDN must route each user to the optimal edge server. "Optimal" considers geographic distance, network conditions, and server load.
DNS-Based Routing
The most common approach. CDN's authoritative DNS server returns different IP addresses based on the user's location (determined by the DNS resolver's IP).
Pros: Works with all clients, no special network setup Cons: Location based on DNS resolver (not always accurate), slow failover due to DNS TTL caching
Anycast
All edge servers advertise the same IP address via BGP. The network naturally routes packets to the nearest server.
Pros: Instant failover (network reroutes automatically), simple for clients Cons: Requires BGP control, can cause session affinity issues with TCP
HTTP Redirect
Client first contacts a router service, which redirects to the optimal edge server.
GET /image.png HTTP/1.1
Host: cdn.example.com
HTTP/1.1 302 Found
Location: https://edge-tokyo.cdn.example.com/image.png
Pros: Can make sophisticated routing decisions, works with any DNS Cons: Extra round-trip for first request
Comparison
| Method | Latency | Failover Speed | Accuracy |
|---|---|---|---|
| DNS-based | Low | Slow (TTL) | Good |
| Anycast | Lowest | Instant | Network-based |
| HTTP redirect | Higher (+1 RTT) | Fast | Best |
Interview mention: "We'd use DNS-based routing for most cases—it's simple and effective. For critical real-time applications, anycast provides instant failover. The CDN provider handles this complexity; we'd configure routing policies through their dashboard."
Multi-Tier CDN Architecture
Large CDNs use a hierarchical structure to efficiently distribute content and handle cache misses.
Two-Tier Architecture
- Edge servers (L1): Closest to users, serve hot content
- Parent/Shield servers (L2): Larger caches, absorb cache misses from multiple edges
Benefits:
- Reduces origin load—parent servers aggregate cache misses
- Improves cache hit ratio—parent has aggregated demand from multiple edges
- Handles long-tail content—less popular content cached at parent level
Shield/Origin Shield
A single parent server (or small cluster) that all edge servers consult on cache miss before hitting origin.
User → Edge (miss) → Shield (hit) → Return content
User → Edge (miss) → Shield (miss) → Origin → Shield → Edge → User
This dramatically reduces origin load—instead of thousands of edge servers hitting origin, only the shield does.
In interviews: "We'd configure an origin shield in front of our servers. When edge caches miss, they check the shield first. This collapses thousands of concurrent requests during a cache miss into a single origin request."
CDN Providers
Most companies don't build their own CDN—they use a provider. Here's a comparison of major options.
| Provider | Strengths | Best For |
|---|---|---|
| Cloudflare | Free tier, DDoS protection, edge computing (Workers) | Websites, APIs, startups |
| AWS CloudFront | AWS integration, Lambda@Edge | AWS-based applications |
| Akamai | Largest network, enterprise features | Large enterprises, media |
| Fastly | Real-time purging, edge computing (Compute@Edge) | Dynamic content, APIs |
| Google Cloud CDN | GCP integration, global anycast | GCP-based applications |
When to Build Your Own CDN
Companies like Netflix (Open Connect) and Facebook build their own CDNs when:
- Traffic volume makes third-party CDN costs prohibitive
- They need specialized optimizations (Netflix's video streaming)
- They want complete control over the delivery path
- They have sufficient scale to justify the infrastructure investment
For most companies, using a CDN provider is the right choice—lower cost, faster deployment, and broader geographic coverage.
Interview guidance: Default to mentioning a CDN provider appropriate to the context: "We'd use CloudFront since we're on AWS" or "Cloudflare for their DDoS protection and edge workers." Only discuss building your own CDN if specifically asked or if the scale clearly warrants it (Netflix-level traffic).
Common Interview Patterns
CDN in System Architecture
Most system designs follow this pattern:
Users → CDN → Load Balancer → Application Servers → Database
↓
Origin/API
- CDN handles static assets and cacheable API responses
- Load balancer routes to application servers
- Application servers generate dynamic content
CDNs and distributed caches serve different purposes: CDNs cache content at the edge (close to users) to reduce latency, while distributed caches like Redis cache data internally (close to your servers) to reduce database load. A typical architecture uses both: CDN for static assets, Redis for session data and database query results.
What to Cache at CDN Level
| Cache | Don't Cache |
|---|---|
| Images, videos, audio | User-specific data |
| CSS, JavaScript bundles | Authentication tokens |
| Fonts, icons | Shopping carts |
| Public API responses | Payment information |
| HTML pages (if not personalized) | Real-time data (stock prices) |
Cache-Control Headers
# Aggressive caching for versioned static assets
Cache-Control: public, max-age=31536000, immutable
# Short caching for API responses
Cache-Control: public, max-age=60, s-maxage=300
# No caching for sensitive data
Cache-Control: private, no-store
# Stale-while-revalidate for best UX
Cache-Control: public, max-age=60, stale-while-revalidate=3600
Common Follow-up Questions
Q: How do you handle cache invalidation when content changes?
"For static assets, we use content-addressed URLs—the hash of the file is in the filename, so when content changes, the URL changes and there's nothing to invalidate. For API responses, we use short TTLs with stale-while-revalidate so users get fast responses while we update in the background. For urgent updates, we use the CDN's purge API."
Q: How do you handle personalized content with a CDN?
"We separate cacheable from non-cacheable parts. The page structure and common elements are cached with long TTLs. Personalized elements are either loaded client-side via JavaScript or assembled at the edge using ESI. For APIs, we cache by cache key that includes relevant parameters but excludes user identity for public data."
Q: What happens during a cache stampede?
"When a popular item's cache expires, thousands of requests could hit origin simultaneously. We'd use request coalescing at the edge—the CDN collapses concurrent requests for the same URL into a single origin fetch. We'd also use stale-while-revalidate to serve slightly stale content while refreshing in the background."
Quick Reference
Push vs Pull Selection
| Scenario | Model | Reasoning |
|---|---|---|
| Static website | Pull | Simple, caches on demand |
| Video streaming | Push | Pre-position popular content |
| E-commerce catalog | Pull | Long-tail of products |
| Breaking news | Push | First-request latency critical |
| User uploads | Pull | Unpredictable what's popular |
| Software downloads | Push | Known popular files |
TTL Guidelines
| Content Type | TTL | Cache-Control Header |
|---|---|---|
| Versioned assets | 1 year | max-age=31536000, immutable |
| Images | 1-7 days | max-age=86400 |
| HTML pages | 1-60 minutes | max-age=300, s-maxage=3600 |
| API (public) | 1-5 minutes | max-age=60, stale-while-revalidate=300 |
| API (private) | 0 | private, no-store |
Interview Checklist
When discussing CDN in your design:
- Identified what content to cache (static vs dynamic)
- Chose appropriate CDN model (pull for most cases)
- Set reasonable TTLs based on content type
- Addressed cache invalidation strategy
- Mentioned versioned URLs for static assets
- Discussed how users are routed to edge servers
- Named specific technology (CloudFront, Cloudflare, etc.)
- Addressed cache stampede/thundering herd
- Mentioned origin shield for reducing origin load
- Connected CDN to overall architecture (CDN → LB → App → DB)
What Interviewers Look For
-
Understanding of purpose — You know CDNs reduce latency by serving content from edge locations, not just that "you need a CDN."
-
Push vs pull awareness — You can explain when each model applies and default to pull for most scenarios.
-
Cache consistency trade-offs — You understand TTL trade-offs and can articulate cache invalidation strategies including versioned URLs.
-
Practical knowledge — You mention specific providers (CloudFront, Cloudflare), understand Cache-Control headers, and know about origin shields.
-
Integration thinking — You show how CDN fits into the overall architecture and what content belongs at the CDN layer vs application layer.
CDNs are foundational infrastructure—they enable global performance but aren't usually the interesting part of your design. Demonstrate competence quickly: "We'll use CloudFront for static assets with 24-hour TTLs and versioned URLs. API responses get 1-minute TTLs with stale-while-revalidate." Then move on to the unique aspects of your system.