Design a Global Content Distribution Network

When a user in Tokyo loads a webpage hosted in Virginia, the speed of light alone adds 150ms of round-trip latency. A CDN eliminates that penalty by serving cached content from a nearby edge server, turning a 200ms origin fetch into a sub-10ms cache hit. Designing a global CDN means designing the caching and routing infrastructure that makes the internet feel fast.

Functional

Content distribution via edge servers: Deliver static content (images, CSS, JS, video) and dynamic content from geographically distributed edge locations. Edge servers cache copies of content so users never wait for origin round-trips.

CDN numbers are dominated by one metric: cache hit ratio. A large CDN handles billions of requests per day, but if the cache hit ratio is 95%, the origin sees only 5% of that traffic. Capacity planning for a CDN is fundamentally about maximizing cache hits and sizing infrastructure for the remaining misses.

Traffic

Global CDN: 10 billion requests/day, roughly 115K QPS average, peaks at 5-10x during events. 50-200 PoPs worldwide, 5-50 edge servers per PoP. Target cache hit ratio: 95%+ for static content, 40-70% for dynamic. At 95% CHR, origin handles roughly 5,750 QPS (5% of 115K).

A CDN has two distinct API surfaces: the HTTP caching protocol (Cache-Control headers, conditional requests, ETags) that governs how content flows between origin, edge, and browser, and the management API that lets operators configure distributions, purge caches, and monitor performance. The caching protocol is the real API of a CDN. The management API is the control plane.

HTTP Caching Protocol (Data Plane)

Cache-Control headers control content freshness: max-age, s-maxage, no-cache, no-store, private, public. Conditional requests with If-None-Match (ETag) and If-Modified-Since enable efficient revalidation. The stale-while-revalidate and stale-if-error directives provide resilience without sacrificing user experience.

A CDN does not have a traditional database the way a social network or e-commerce platform does. The edge cache IS the primary data store, a distributed key-value store where the key is the cache key (URL + headers) and the value is the complete HTTP response. But the control plane needs persistent storage for distribution configs, routing rules, and analytics.

Edge Cache Storage (Data Plane)

1Cache Key: scheme + host + path + sorted_query_params + Vary headers
2Value: {
3http_status: 200,
4headers: { "Content-Type": "image/jpeg", "ETag": "abc123", ... },
5body: <binary content>,
6metadata: { cached_at: timestamp, ttl: 3600, tags: ["product-123"] }
7}

A CDN is an inverted tree. The origin server at the root holds authoritative content. An optional origin shield layer aggregates cache misses. Hundreds of edge PoPs at the leaves serve users worldwide. DNS routing (GeoDNS or Anycast) directs each user to their nearest leaf. The entire architecture exists to keep traffic at the edges and away from the root.

Edge Server Network (PoPs)

Understanding a CDN means tracing two flows: the content delivery flow (read path, how a user gets content from the nearest edge) and the cache invalidation flow (write path, how content updates propagate across all edges). The read path is optimized for speed. The write path is eventually consistent by design.

Flow 1: Content Delivery (Read Path)

If the CDN architecture is the skeleton, the edge cache engine is the heart. Every request passes through the same critical decision point: is this content in cache (serve in sub-10ms) or not (fetch from origin at 200ms+)? This section deep-dives into the edge cache engine: the caching, coalescing, invalidation, and resilience mechanisms that determine whether the CDN delivers on its latency promise.

The Edge Cache Engine (GATE)

A CDN makes one overarching trade-off: latency over freshness. The entire system is eventually consistent by design. When origin content changes, the world does not see it instantly. It sees it as TTLs expire and caches refresh. This is deliberate, and for 99% of content, it is the right choice.

Cache Freshness vs. Latency

Long TTL (86400s): maximizes CHR, minimizes origin load, but content updates take up to 24 hours to propagate. Ideal for versioned assets (main.abc123.js) where the URL changes when content changes.

A CDN is designed to survive failure. Edge PoPs fail, origin servers go down, DDoS attacks flood the network. The architecture's resilience comes from redundancy at every tier: multiple PoPs per region, origin shielding, stale-serving directives, and DNS-based rerouting. But when failures cascade (like the 2021 Fastly outage that took down Amazon, Reddit, and the UK government website for 49 minutes) the impact is global.

Edge Server / PoP Failure

CDNs started as simple caching proxies for static files. They have evolved into programmable edge computing platforms. The next generation of CDN improvements move computation to the edge, use AI for predictive caching, and enable multi-provider architectures that survive provider-level failures.

Edge Computing (Lambda@Edge, Cloudflare Workers)

Run serverless functions at edge locations. Code executes at the PoP closest to the user. Use cases: A/B testing at edge (no origin round-trip), personalized content assembly (merge cached template with user-specific data), request routing logic, authentication at edge (JWT validation without origin call). Turns CDN from a caching layer into a programmable application platform.