Loading system design…
Loading system design...
Design a globally distributed Content Delivery Network (CDN) like Cloudflare, Akamai, or AWS CloudFront. The CDN caches and serves static content (images, CSS, JS, videos) from edge servers geographically close to users, dramatically reducing latency and offloading traffic from origin servers.
| Metric | Value |
|---|---|
| Edge Points of Presence (PoPs) | 200–300 globally |
| Total bandwidth served | 100+ Tbps (terabits per second) peak |
| Requests served | 50+ billion / day |
| Cache hit ratio (target) | 90–95% (only 5–10% of requests reach origin) |
| Average edge response time | < 10ms for cache hit |
| Origin shield → origin latency | < 50ms (same-region shield) |
| Content types | Static: images, CSS, JS, fonts, video segments; Dynamic: API acceleration |
| Cache storage per PoP | 10–100 TB SSD |
Serve static content (images, CSS, JS, videos, fonts) from edge servers geographically close to the user, minimising latency
Route user requests to the nearest/optimal edge server using DNS-based or Anycast routing
Cache content at edge servers with configurable TTL; serve cache hits without contacting the origin server
Fetch content from the origin server on cache miss, cache it at the edge, and serve it to the user (pull-based CDN)
Support cache invalidation/purge: origin can trigger immediate purge of specific URLs or cache tags across all edge PoPs
Support push-based content distribution: origin pre-pushes content to edge servers before user requests arrive (for known popular content)
Handle TLS termination at the edge: serve HTTPS with per-domain SSL certificates and HTTP/2 support
Provide origin shielding: a mid-tier cache layer between edges and origin to reduce origin load during cache misses
Support dynamic content acceleration: TCP optimisation, connection keep-alive, and route optimisation for non-cacheable requests
Provide real-time analytics: cache hit ratio, bandwidth served, latency per PoP, error rates, top requested URLs
Non-functional requirements define the system qualities critical to your users. Frame them as 'The system should be able to...' statements. These will guide your deep dives later.
Think about CAP theorem trade-offs, scalability limits, latency targets, durability guarantees, security requirements, fault tolerance, and compliance needs.
Frame NFRs for this specific system. 'Low latency search under 100ms' is far more valuable than just 'low latency'.
Add concrete numbers: 'P99 response time < 500ms', '99.9% availability', '10M DAU'. This drives architectural decisions.
Choose the 3-5 most critical NFRs. Every system should be 'scalable', but what makes THIS system's scaling uniquely challenging?
The complete explanation is included with Career and All Access. Compare it with your approach once you’ve worked through the problem.
Your system-design submission history is available after you sign in.
Sign In