A Content Delivery Network (CDN) is a globally distributed network of servers that caches content closer to users. CDNs dramatically reduce latency and improve availability for static and cacheable content.
Why CDNs Matter
Without a CDN:
- Users far from your servers experience high latency
- Your origin servers handle all traffic
- Geographic redundancy is expensive
- Traffic spikes can overwhelm your infrastructure
With a CDN:
- Content served from the nearest edge location
- Origin servers protected from direct traffic
- Global availability built-in
- Traffic spikes absorbed by distributed cache
For any user-facing application with global users, a CDN is almost always part of the solution.
How CDNs Work
User in Tokyo → CDN Edge (Tokyo) → Cache hit → Return content
→ Cache miss → Origin (US) → Cache → Return
Subsequent requests from Tokyo region → Cache hit → Fast response
Key Concepts
| CDN Terminology | |
|---|---|
| Name | Description |
Edge location | CDN server close to users. Hundreds globally for major CDNs. |
Origin | Your server or storage (S3, app server) where content lives. |
Cache hit | Content found at edge, served directly. Fast. |
Cache miss | Content not at edge, fetched from origin. Slower, then cached. |
TTL (Time To Live) | How long content stays cached before refresh. |
Cache invalidation | Forcing cache to fetch fresh content before TTL. |
CDN Providers
| Popular CDN Providers | |
|---|---|
| Name | Description |
CloudFront | AWS CDN. Deep AWS integration. Good default for AWS users. |
Cloudflare | Large network, strong DDoS protection, generous free tier. Popular choice. |
Akamai | Enterprise-grade, largest network. Higher cost, premium features. |
Fastly | Real-time purging, edge computing. Good for dynamic content. |
Google Cloud CDN | GCP integration. Good for GCP-native applications. |
What to Cache
Always Cache
- Static assets (JS, CSS, images)
- Public content that doesn't change (documentation, marketing pages)
- Media files (videos, podcasts)
- API responses that are the same for all users
Sometimes Cache
- Semi-static content with appropriate TTL
- Public API responses (with short TTL)
- Personalized content (using edge computing)
Never Cache
- User-specific private data
- Authentication tokens
- Real-time data (stock prices, live scores)
- POST/PUT/DELETE responses
CDN Caching Decision
You're building a news website. Which content would you cache at the CDN, and with what TTL?
See recommended approach
Cache with long TTL (1 day+):
- Static assets (CSS, JS, fonts, images)
- Old articles (won't change)
- Author profile images
Cache with medium TTL (5-15 minutes):
- Homepage HTML (updates with new articles)
- Category pages
- Article pages (may have updates/corrections)
Cache with short TTL (1 minute):
- Trending/popular articles list
- Comment counts (shown on article cards)
Don't cache:
- User authentication state
- Personalized recommendations
- Comment submission endpoints
Key insight: Different parts of the same page can have different caching strategies. The article HTML might be cached, but a "trending now" widget fetched dynamically.
Cache Control Headers
Control caching behavior via HTTP headers:
Cache-Control: public, max-age=86400
| Cache-Control Directives | |
|---|---|
| Name | Description |
public | Can be cached by CDN and browsers. |
private | Only browser can cache, not CDN. Use for user-specific data. |
max-age=N | Cache for N seconds. |
s-maxage=N | CDN cache time (overrides max-age for CDN). |
no-cache | Must revalidate with origin before using cached version. |
no-store | Don't cache at all. Use for sensitive data. |
immutable | Content will never change. Can cache forever. |
Common Patterns
# Static assets with cache busting (file.abc123.js)
Cache-Control: public, max-age=31536000, immutable
# API response that can be cached briefly
Cache-Control: public, max-age=60
# User-specific content
Cache-Control: private, max-age=0, no-store
# Content that might update but can serve stale while revalidating
Cache-Control: public, max-age=60, stale-while-revalidate=300
Cache Invalidation
When content changes, you need to update the cache.
TTL-Based
Wait for cache to expire naturally.
Pros: Simple, no extra complexity Cons: Stale content until expiration
Purge/Invalidation
Actively clear cached content.
# CloudFront invalidation
aws cloudfront create-invalidation \
--distribution-id EXAMPLE \
--paths "/images/*" "/index.html"
Pros: Immediate updates Cons: Takes time to propagate, may have costs
Cache Busting
Include version/hash in filename.
# Old version
<script src="/app.js">
# With cache busting
<script src="/app.abc123.js"> # abc123 is content hash
Pros: Instant update, no invalidation needed Cons: Requires build system support
Cache busting is the most reliable approach for static assets. Use content hashes in filenames and set a long max-age. When content changes, the filename changes, so users get the new version immediately.
CDN Architecture Patterns
Static Content Delivery
Browser → CDN → S3 bucket (origin)
Most common pattern. CDN serves static assets from blob storage.
Full Site Acceleration
Browser → CDN → Application servers
CDN caches dynamic pages too. Useful for mostly-static sites.
API Acceleration
Browser → CDN → API servers
Cache API responses at the edge. Short TTLs for freshness.
Edge Computing
Browser → CDN (runs code at edge) → Origin (sometimes)
Run code at CDN edge locations. Examples: A/B testing, personalization, authentication.
Technologies: Cloudflare Workers, CloudFront Lambda@Edge, Fastly Compute
Level-Based Expectations
| CDN Knowledge by Level | |
|---|---|
| Name | Description |
Mid-Level (L4) | Know to use CDN for static assets. Understand basic caching concepts. Can explain edge locations and latency benefits. |
Senior (L5) | Configure appropriate cache headers. Design cache invalidation strategy. Understand CDN in full architecture context. |
Staff+ (L6+) | Design edge computing solutions. Optimize cache hit ratios. Handle complex invalidation scenarios. Consider cost optimization. |
Engineering Manager | Evaluate CDN vendors and costs. Plan for traffic spikes and DDoS protection. Understand CDN SLA implications. |
Performance Metrics
Cache Hit Ratio
Hit Ratio = Cache Hits / (Cache Hits + Cache Misses)
Target: >90% for static content, >70% for dynamic content.
Improve by:
- Longer TTLs
- More consistent URLs (avoid unnecessary query params)
- Warming popular content
Time To First Byte (TTFB)
Time from request to first byte of response.
CDN impact: Edge serving can reduce TTFB by 100-500ms for distant users.
Common Interview Scenarios
"How do you serve images globally with low latency?"
"I'd store images in S3 and serve them through a CDN like CloudFront. The CDN caches images at edge locations worldwide. Users download from the nearest edge—say, Tokyo for Asian users, Frankfurt for European users. I'd use cache busting with content hashes in filenames and a long max-age, so images are cached until they actually change."
"How do you handle a traffic spike?"
"CDNs are excellent for absorbing traffic spikes. Static content is served from edge cache without hitting our origin. For the origin traffic that does come through, I'd combine the CDN with auto-scaling application servers and rate limiting. The CDN also provides DDoS protection to filter malicious traffic."
"How do you update content that's cached?"
"For static assets, I use cache busting—content hash in the filename. When the file changes, the name changes, and users get the new version. For other content, I have two options: short TTL so it refreshes automatically, or explicit invalidation when content changes. I'd prefer short TTL for simplicity unless freshness requirements are strict."
What's Next
CDNs handle content delivery at the edge. Next, we'll look at rate limiters, which protect your services from abuse and overload.