Overview
A content delivery network (CDN) is a globally distributed network of caching servers (edge locations or points of presence) that serve content from a location close to each user. Instead of every request crossing the world to your origin server, a user in Mumbai is served from Mumbai.
CDNs cut latency, absorb traffic spikes, reduce origin load and bandwidth costs, and provide DDoS protection. They are essential for static assets (images, JS, CSS, video) and increasingly serve dynamic content, APIs, and edge compute.
An online store does not ship every package from one central warehouse. It stocks popular items in regional warehouses near customers, and only rare items come from the main warehouse. Deliveries are faster and the main warehouse is not overwhelmed.
When to use it
- Users are geographically distributed.
- Serving images, video, JavaScript, CSS, and downloads.
- Absorbing traffic spikes (launches, viral content).
- Protecting the origin from DDoS and bots.
- Running lightweight logic near users (edge functions).
Where it shows up in interviews
Recognize it when: images, video, or downloads for a global audience.
- Design YouTube
- Design Netflix
- Design Instagram
Recognize it when: millions of users hit the same content at once.
- Design a flash sale system
- Design live event streaming
Recognize it when: public, cacheable API responses.
- Design a product catalog API
- Design a news feed for anonymous users
Where it is used in real software
Netflix places its own caching appliances inside ISP networks, serving most video traffic without crossing the internet backbone.
Commercial CDNs with hundreds of edge locations that also provide WAF, DDoS protection, and edge compute.
Fastly and Cloudflare can purge content globally within seconds, enabling long TTLs with instant invalidation.
Key terms
- Edge / PoP
- A CDN data center near users.
- Origin
- Your server or storage that holds the source of truth.
- Cache hit ratio
- Fraction of requests served from the edge without contacting the origin.
- TTL / Cache-Control
- How long the edge may serve a cached copy.
- Origin shield
- A mid-tier cache that collapses many edge misses into one origin request.
How it works, step by step
- 1DNS routes the user to a nearby edge
Via anycast or geo DNS.
- 2Edge checks its cache
Cache key is usually host + path (+ selected headers or query params).
- 3Hit: serve immediately
Latency is only the short trip to the edge.
- 4Miss: fetch from shield or origin
Store the response according to Cache-Control, then serve it.
- 5Invalidate when content changes
Purge by URL or tag, or use versioned file names so new content has new URLs.
STEP 1The first user requests /img/hero.webp. The Mumbai edge has no copy (miss).
Impact of a CDN on a global image site
Origin in us-east-1, 10,000 req/s of images, 95% hit ratio
| Metric | Without CDN | With CDN |
|---|---|---|
| Latency for EU / Asia users | 150-300 ms | 10-40 ms (hits) |
| Origin requests | 10,000 / s | 500 / s |
| Origin bandwidth | 100% | ~5% |
| Spike of 10x traffic | Origin overload | Absorbed by edges |
NOWMetric: Latency for EU / Asia users | Without CDN: 150-300 ms | With CDN: 10-40 ms (hits)
A high hit ratio is what makes a CDN effective. Improve it with long TTLs on versioned assets, normalized cache keys, and an origin shield.
Implementation
# Versioned static asset: cache for a year, never revalidateGET /assets/app.3f9a2c.jsCache-Control: public, max-age=31536000, immutable # HTML: always check freshness, allow CDN to serve brieflyGET /index.htmlCache-Control: public, max-age=0, s-maxage=60, stale-while-revalidate=300 # Personalized API: never cache at the CDNGET /api/meCache-Control: private, no-storeComplexity and performance
Depends on proximity.
Higher means cheaper and faster.
Provider dependent.
Trade-offs
Long TTLs maximize hits but risk stale content; use versioned URLs for assets and short TTLs or purges for HTML.
CDN bandwidth is cheaper than origin egress at scale, but you depend on a third party and its outage can take your site down.
Variants and related techniques
Pull CDNs fetch from the origin on demand (most common); push CDNs require you to upload content ahead of time.
Cloudflare Workers, Lambda@Edge, and Fastly Compute run code at the edge for auth, A/B tests, and personalization.
Segmented HLS/DASH files are highly cacheable and served almost entirely from the CDN.
Common mistakes
- Caching personalized responses publicly.
Fix: Mark them private or no-store, and never cache responses with Set-Cookie at the edge.
- Query parameters fragmenting the cache.
Fix: Normalize or ignore irrelevant parameters (utm_source) in the cache key.
- Relying on purges for every deploy.
Fix: Use content-hashed file names so new versions are new URLs.
Interview questions
How do you invalidate CDN content?
Prefer versioned URLs so updates never need invalidation. For content at fixed URLs (HTML, API), use short TTLs with stale-while-revalidate, or purge by path or surrogate key after changes.
What is an origin shield?
A regional cache layer between edges and the origin. Misses from many edges become a single origin request, protecting the origin and improving hit ratios.
Can a CDN help with dynamic content?
Yes: it terminates TLS near the user, reuses warm connections to the origin, can cache short-lived responses, and can run edge logic. Truly personalized data still comes from the origin.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Write Cache-Control headers for assets, HTML, and APIs | Easy | Cache semantics. |
| Design image delivery for Instagram | Medium | CDN, resizing, cache keys. |
| Design video delivery for a live sports event | Hard | Segments, origin shield, spikes. |