Content Delivery Network (CDN)
CDNs are essential for any user-facing application. They reduce latency, reduce origin server load, protect against DDoS attacks, and handle traffic.
Quick answer: Content Delivery Network (CDN)
Content Delivery Network (CDN) is covered here as a practical system design concept. CDNs are essential for any user-facing application. They reduce latency, reduce origin server load, protect against DDoS attacks, and handle traffic. Use it to understand the Caching idea, where it appears in production systems, and how to discuss it clearly in interviews.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
A CDN (Content Delivery Network) caches content at edge servers distributed across the globe, serving requests from the location nearest to the user instead of from the origin server. For static content like images, CSS, and JavaScript, a CDN reduces latency from 200ms+ to under 20ms. Cloudflare, AWS CloudFront, and Akamai are the most widely deployed CDNs, collectively serving a majority of all internet traffic.
| Aspect | Details |
|---|---|
| What it is | A global network of edge servers that cache and serve content close to users |
| When to use | Static assets (images, CSS, JS), video streaming, global user base, any public cacheable content |
| When NOT to use | Personalized/authenticated content; internal APIs; real-time dynamic data that cannot be cached |
| Real-world example | Netflix Open Connect serves 15%+ of global internet traffic; Cloudflare protects 20M+ websites at the edge |
| Interview tip | Discuss cache invalidation at the edge — how do you update content across 300+ global PoPs? |
| Common mistake | Caching authenticated or personalized responses at the CDN — serves user A's data to user B |
| Key tradeoff | Dramatically lower latency and origin load vs. cache invalidation complexity and propagation delay |
When You Need Content Delivery Network (CDN)
CDNs are essential for any user-facing application. They reduce latency, reduce origin server load, protect against DDoS attacks, and handle traffic spikes. Without a CDN, users far from your server experience poor performance.
What It Is
A CDN is a network of geographically distributed edge servers that cache and serve content close to users. When you visit a website using Cloudflare or Akamai, static assets (images, CSS, JS) are served from a nearby edge server instead of the origin server, reducing latency from 200ms to 20ms.
How It Works
When a user in Tokyo requests an image from your server in US East:
- Without CDN: Request travels to US East (200ms round trip), downloads image (500ms). Total: 700ms.
- With CDN: Request goes to Tokyo edge server (5ms). If cached, serve immediately. If not, edge fetches from origin (200ms) and caches it. First user: 205ms. All subsequent Tokyo users: 5ms.
The CDN handles geographic routing using DNS (returns the IP of the nearest edge) or Anycast (BGP routes to nearest edge).
The Decision Framework
- Edge servers: Servers placed in 100+ cities worldwide. Content is cached at the edge closest to the user.
- Cache hit/miss at edge: If the edge has the content (hit), serve directly. If not (miss), fetch from origin, cache at edge, then serve.
- TTL and cache-control: HTTP headers (Cache-Control, Expires) tell the CDN how long to cache content.
- Push vs Pull CDN: Pull CDN fetches content from origin on first request. Push CDN requires you to upload content to the CDN in advance.
- Dynamic content: Modern CDNs (Cloudflare Workers, AWS Lambda@Edge) can also process dynamic requests at the edge.
What the Industry Uses
Netflix uses its own CDN (Open Connect) with servers embedded in ISP networks, serving 15% of global internet traffic.
Cloudflare operates 300+ edge locations, handling 20% of all internet traffic.
Shopify uses Cloudflare to cache storefront assets, reducing page load times by 50-70%.
Performance and Tradeoffs
- Freshness vs Performance: Longer cache TTL = faster but potentially stale. Cache purging is possible but takes time to propagate.
- Cost: CDN bandwidth is charged per GB. At high scale, CDN costs can be significant.
- Dynamic content: CDNs are designed for static content. Dynamic content requires edge computing or bypassing the CDN.
Mistakes Engineers Make
- Not setting proper Cache-Control headers — CDN may not cache, or may cache too long
- Caching personalized content (user-specific data) on the CDN — serves one user's data to another
- Not purging the CDN cache after deploying new assets
Practice These Interview Questions
- How does a CDN work?
- What content should be served via a CDN?
- What is the difference between push and pull CDN?
- How do you handle cache invalidation on a CDN?
How to Explain This in an Interview
Here is how I would explain Content Delivery Network (CDN) in a system design interview:
A CDN puts copies of your content at edge servers worldwide. When a user in Tokyo requests an image, it loads from a Tokyo edge server in 20ms instead of your US origin in 200ms. I would use a CDN for all static assets unconditionally, and for cacheable API responses with appropriate Cache-Control headers. The key design decisions: TTL (how long edges cache content before revalidating with the origin), cache key (URL plus relevant headers that identify unique resources), and purge strategy (how you invalidate stale content across all edge locations when the origin data changes). When the interviewer asks about dynamic content, explain that you can use short TTLs (30-60 seconds) or stale-while-revalidate to serve slightly stale data while fetching fresh data in the background.
Original DosiBridge notes for Content Delivery Network (CDN)
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Content Delivery Network (CDN) is to connect the concept to a media-heavy path where network variance, buffering, and edge placement decide the user experience. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Freshness Window: For Content Delivery Network (CDN), decide the freshness window before choosing tools; otherwise the design looks clean but fails when cdn changes.
- Eviction Pressure: For Content Delivery Network (CDN), decide the eviction pressure before choosing tools; otherwise the design looks clean but fails when cdn changes.
- Hot Key Behavior: For Content Delivery Network (CDN), decide the hot-key behavior before choosing tools; otherwise the design looks clean but fails when cdn changes.
- Cache Stampede: For Content Delivery Network (CDN), decide the cache stampede before choosing tools; otherwise the design looks clean but fails when cdn changes.
- Invalidation Owner: For Content Delivery Network (CDN), decide the invalidation owner before choosing tools; otherwise the design looks clean but fails when cdn changes.
Production review question
If a team adopts Content Delivery Network (CDN), what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track cdn health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Content Delivery Network (CDN), this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.
Further Reading
