Blog
CDN in System Design: When and How to Use a Content Delivery Network
March 5, 2026 · Updated March 5, 2026 · 9 min read
Learn when a CDN actually helps, how edge caching works, and the cache-key and purge decisions that matter in real architectures.
Definition
A Content Delivery Network (CDN) is a geographically distributed layer of edge servers that cache and serve content closer to users, reducing latency and origin load.
Implementation Checklist
- Identify which responses are cacheable (static assets, public API responses, pre-rendered pages) before enabling CDN.
- Define explicit cache-key rules so query parameters, headers, and cookies do not fragment your hit rate.
- Set up origin shielding to collapse edge misses into a single origin request instead of a thundering herd.
- Build a purge pipeline that can invalidate by path, tag, or surrogate key within your deployment flow.
- Monitor cache hit ratio, origin bandwidth, and edge error rates as primary CDN health signals.
How CDN Caching Actually Works
Edge servers cache responses based on URL, headers, and cache-control directives. A cache hit serves the response directly from the nearest edge. A cache miss forwards the request to origin, caches the response, and serves it.
Cache-key design is the most underestimated CDN decision. Unnecessary query params or cookies in the key fragment your cache and destroy hit rates. Strip everything that does not affect the response body.
CDN in System Design Interviews
Interviewers expect you to know when a CDN helps and when it does not. Place the CDN between DNS and your load balancer. Explain what you cache, how you invalidate, and what happens on a cache miss.
Common follow-ups: How do you handle cache stampede on popular content? How do you purge after a deploy? How does the CDN affect your latency SLA? Prepare concrete answers for each.
Operational Checklist for Production CDNs
Monitor three metrics daily: cache hit ratio (target above 90% for static), origin bandwidth (should stay flat under traffic growth), and edge error rate (5xx from edge vs origin).
Automate cache purge in your CI/CD pipeline. Manual purge processes break during incidents when speed matters most.
Tradeoff Table
| Decision | Speed-First Option | Reliability-First Option | Recommended When |
|---|---|---|---|
| CDN for dynamic vs static content | Cache everything including short-TTL API responses for maximum edge hit rate. | Only cache static assets and use pass-through for dynamic content to avoid stale data. | Cache static assets by default. Add dynamic edge caching only after measuring staleness tolerance per endpoint. |
| Push purge vs TTL expiry | Long TTL with rare purges maximizes hit rate and minimizes origin traffic. | Short TTL or event-driven purge keeps edge content fresh without manual intervention. | Use event-driven purge for user-facing content that changes on write. Use long TTL for truly immutable assets. |
| Single CDN vs Multi-CDN | Single CDN is simpler to configure, monitor, and debug. | Multi-CDN adds failover and better regional coverage at the cost of operational complexity. | Start with one CDN. Add a second only when availability SLA demands or regional latency gaps justify it. |
Practice Next
CDN Topic Hub
Deep dive into CDN architecture, edge caching strategies, and system design tradeoffs.
CDN and Edge Computing Lab
Practice adding a CDN layer to an architecture and measuring latency improvements.
Challenges
- Design Video Streaming
Apply CDN edge caching for media delivery at global scale.
- Medium CDN Challenge
Design a CDN from scratch with edge PoPs, origin shielding, and cache invalidation.
Newsletter CTA
Join the SystemForces newsletter for practical architecture notes every week.
Get weekly system design breakdownsFrequently Asked Questions
When should I skip using a CDN?
Skip a CDN when all users are in one region close to your origin, when content is mostly non-cacheable authenticated data, or when your traffic volume does not justify the cost.
How does a CDN interact with load balancers?
The CDN sits in front of your load balancer. Cache hits never reach origin. Cache misses flow through the load balancer to your app servers as normal.
What is origin shielding and do I need it?
Origin shielding consolidates cache-miss requests from multiple edge PoPs into a single shield node, reducing origin load during cold-cache events. Use it when your origin cannot handle burst miss traffic.