Designing a Global CDN (Content Delivery Network)

We need to design a global CDN that serves static assets, software downloads, images, APIs, and large media files with low latency across continents while reducing origin load and remaining resilient to edge failures, traffic spikes, and attacks.

Without a CDN, a user in Singapore fetching an asset from a US-only Origin Server might pay roughly 150–250 ms RTT (approximate, varies with path and network) before payload transfer even begins. That delay comes from physics as much as software: TCP handshake, TLS handshake, and the first byte all have to cross oceans. If the page needs dozens of assets, those round trips compound into a slow product.

Why this system is interesting

CDNs are one of the clearest examples of architecture shaped by geography. The core problem is not only throughput; it is where the bytes live. A good CDN shortens the path for Cache Hits, collapses Cache Misses behind a Regional Shield Cache, routes users toward the nearest healthy Edge PoP, and pushes security controls such as WAF and DDoS scrubbing to the network edge.

Workload classes this design must account for

Not all traffic behaves the same way, and the design should say so explicitly rather than implying uniform caching everywhere: immutable static assets (fingerprinted bundles, images), mutable static or semi-static content (a logo that changes occasionally, a homepage HTML shell), large downloads, segmented media (video/audio), cacheable API responses (public, non-personalized), and personalized or auth-sensitive content that should bypass shared caching entirely. Each class gets a different freshness and caching treatment throughout this design.

Functional requirements describe what the CDN must do for application teams, operators, and end users.

Non-functional requirements are what turn a reverse proxy into a global platform.

Good scope discipline keeps the design centered on content delivery rather than every adjacent networking feature.

In scope

Global edge delivery, static and media caching, DNS-based Geo-Routing and Anycast Routing, Regional Shield Cache design, explicit purge, TTL policies, signed delivery, TLS termination, WAF/DDoS controls, video segment caching, and multi-region origin failover.

Out of scope

Authoritative DNS platform internals, custom backbone peering economics, certificate-authority implementation, full video transcoding pipelines, application business logic, and deep browser rendering optimization. Those systems exist around a CDN, but they are not required to explain the core delivery architecture cleanly.

Capacity planning for a CDN is driven by request volume, byte volume, and how much of that traffic can be served as a cache hit instead of an origin fetch.

Traffic assumptions

The numbers below are illustrative design assumptions, not measured facts about any real deployment — they exist to reason about order of magnitude. Assume 40 million DAU worldwide, as an illustrative example.

Bandwidth math

Assume the blended average object or segment size is 400 KB. Daily egress is 1.2B × 400 KB = 480 TB/day. Spread across a day, that is about 44 Gbps average; at a 12× peak, the platform should be comfortable around 530 Gbps peak edge egress before adding headroom. Popular video or game-download events can exceed the blended average sharply, so operators usually provision extra regional margin.

Why cache hit ratio changes everything

These hit-ratio figures are illustrative assumptions for this design, not verified production numbers. Note also that request hit ratio (the fraction of requests served from cache) and byte hit ratio (the fraction of bytes served from cache) are different metrics — a cache can look excellent on one and mediocre on the other, especially with large-object traffic. If the edge achieves an illustrative 93% request hit ratio, only 7% of requests become edge misses.

Control-plane and metadata scale

Suppose the CDN manages 200k customer domains, 20 cache rules/domain on average, and 50 purge jobs/minute during busy hours. The metadata store is not massive by big-data standards, but it is latency-sensitive because every Edge PoP depends on fast config distribution, cert lookups, routing health, and purge fan-out state.

Capacity planning is regional, not just global

A single global average hides real pressure. Capacity planning needs to be regional/PoP-aware, because demand, hit ratio, and headroom all vary by geography. Bandwidth is also not the only constraint worth tracking — connection handling, TLS handshake throughput, and CPU capacity at each PoP can become the binding constraint well before raw bandwidth does.

The request path has two very different personalities: the fast Cache Hit path and the slower Cache Miss path. A good design optimizes the first and carefully contains the second.

Cache miss flow

A client resolves the CDN hostname and reaches the nearest healthy Edge PoP. The edge computes the cache key, checks in-memory and SSD tiers, and records a Cache Miss. Instead of every edge going straight to origin, the miss usually walks through a Regional Shield Cache / Origin Shielding tier. If the shield also misses, it fetches from the Origin Server or Origin Load Balancer + replicas, receives response headers such as Cache-Control, stores the object in shield and edge caches, and finally returns it to the client.

Cache hit flow

On a warm request, the same Edge PoP computes the same cache key and immediately finds the object in memory or on local SSD. The response is served directly from the edge, often in ~5–15 ms rather than the ~100–250+ ms of a global miss path. That is why routing users to a well-chosen PoP matters so much: once the object is warm at that PoP, geography mostly disappears from the critical path.

Dynamic and personalized exceptions

Not every request should be cached broadly. Dynamic Content / Personalized Responses may include cookies, auth-specific bodies, cart state, or user-targeted HTML. The edge can still terminate TLS, enforce WAF, and even cache small fragments or use edge-side includes, but the core payload may bypass the shared cache or use a tiny TTL with revalidation.

The revalidation path in between

Between a full hit and a full miss sits a third path worth naming explicitly: client → edge finds a stale-but-revalidation-eligible object → conditional request upstream → `304` (reuse) or new `200` (replace) → refresh local metadata/object → serve. This is cheaper than a cold miss because no full body transfer is needed on a 304, and it is a different case from a plain hit because the edge does contact upstream. A fresh hit, a stale-but-serveable object, a revalidation candidate, a cold miss, and an explicit cache bypass are five distinct outcomes worth distinguishing when reasoning about this system — not just "hit" and "miss." The full mechanics live in Architecture Deep Dive's HTTP Cache Freshness and Revalidation.

CDNs expose both a data plane and a control plane. The data plane is mostly HTTP semantics; the control plane configures policy, purge, and secure access.

Response headers drive caching

The data plane stays HTTP-native so application teams can use familiar headers like Cache-Control, ETag, Last-Modified, and Accept-Ranges — these are standard HTTP caching semantics, not a proprietary CDN API surface.

Purge is an asynchronous control-plane action

A purge request should return quickly with a job ID, and that job ID should support a separate status lookup so callers can ask "has this purge finished propagating?" instead of only firing purges blind.

The CDN control plane exists to answer one question for every edge request: what are the rules for this domain, path, and customer right now?

The data plane should continue serving traffic from a local snapshot even if the central control plane is having a bad day. That separation lets existing configs survive temporary metadata-store issues while new changes queue for later distribution.

Safe rollout sequence for config changes

A concrete sequence keeps a bad config change from becoming a global incident: author config → validate → persist a new version → canary on a limited set of PoPs → observe → progressive regional rollout → fleet-wide convergence → rollback if unhealthy. Every step after authoring can be automated, but none of them should be skipped just because a change looks small.

CDN caching is usually multi-tier because no single storage medium is ideal for every object size and traffic pattern.

Edge in-memory tier

The hottest small objects live in RAM for the fastest possible response path. Memory cache is perfect for tiny JS bundles, thumbnails, auth metadata, and recently popular segments, but it is too expensive to hold the whole global working set.

Edge SSD tier

Local SSD extends the working set dramatically. It is slower than RAM but still far closer than origin. Large images, package downloads, and warm-but-not-hot objects usually live here. SSD is also where the edge can persist objects across short process restarts.

Regional Shield Cache

The shield tier sits between many edges and a smaller set of origins. It improves hit ratio on long-tail objects, enables request coalescing, and prevents 50 PoPs from asking origin for the same newly expired object simultaneously.

Eviction and freshness

TTL answers 'is this object still fresh?' Eviction answers 'do we still have room for it?' Production systems combine size-aware admission with policies inspired by LRU, LFU, or TinyLFU. Large cold files should not crowd out a huge volume of hot small objects just because they arrived recently.

The cache key decides what's actually being cached

Every tier above assumes a well-formed cache key: derived from hostname, normalized path, a deliberately selected set of query parameters, and any explicitly approved variance dimensions. A looser key improves apparent hit ratio but risks correctness; a stricter key is safer but caches less broadly. The full mechanics — including how this goes wrong — are in Architecture Deep Dive's Cache Key Design and Normalization.

Not just 200s: negative caching

The cache can also briefly hold selected non-success responses — a 404 for a path that gets hammered by bots is a common example — so origin is not re-asked the same question on every request. This needs to be status- and content-class-aware, since caching errors too aggressively can hide a resource that just became available.

An Edge PoP is not one server. It is a small platform packaged close to eyeballs.

Data-plane services inside a PoP

A typical PoP contains L4/L7 ingress, TLS termination, reverse proxies, cache processes, local metadata snapshots, health probes, and observability agents. Requests should stay inside the PoP for the common case: accept connection, compute cache key, serve bytes, emit metrics.

Storage and durability inside the PoP

Memory and SSD caches are local and disposable; they are performance layers, not durable truth. If a PoP fails, the CDN repopulates it from shield or origin. That is why warmup strategies matter for newly added capacity or after rolling restarts.

Config sync and blast-radius control

Every PoP runs a config sync agent that receives versioned rule updates, cert bundles, WAF rule sets, and origin maps. Rollouts should be staged region by region because one bad rule pushed globally can create a worldwide outage in seconds.

Client protocol termination: HTTP/1.1, HTTP/2, HTTP/3

The edge is the natural place to terminate the client's transport protocol — HTTP/1.1, HTTP/2 multiplexed over TCP, or HTTP/3 over QUIC/UDP with independent per-stream loss recovery and connection migration. HTTP/3 is not universally faster than HTTP/2; its benefit is conditional on network conditions (lossy or mobile links, many concurrent streams) rather than automatic. The protocol used toward origin can differ from the protocol used toward the client.

Multi-tenancy inside a shared PoP

A PoP serves many customers on shared CPU, memory, bandwidth, connection, WAF, and cache capacity. Quotas and admission control per tenant keep one customer's traffic — or one bad release — from degrading service for every other customer sharing that location.

Routing decides which edge sees the first packet. That decision shapes latency, failover behavior, and operational complexity.

DNS-based Geo-Routing

In an earlier design, the CDN can answer DNS queries with region-specific PoP addresses based on resolver geography or health rules. This is easier to reason about, but DNS answers are sticky because of TTLs and recursive resolver behavior. A user may keep using a suboptimal region until caches expire.

Anycast Routing

BGP path selection steers the client toward a network- and policy-preferred advertisement — which is often a nearby PoP in practice, but is not a guarantee of the geographically nearest location or the lowest application latency. BGP optimizes for network path preference, not for cache warmth or edge CPU utilization.

Failure behavior

DNS and Anycast are not mutually exclusive: DNS provides coarse steering and policy control, while Anycast provides distributed IP reachability with fast packet-level traffic movement when advertisements change. Many production routing strategies combine both rather than picking one and discarding the other. The trade-offs article expands this comparison in detail.

A CDN is a delivery platform and a security perimeter. In practice, many requests hit the edge for security reasons before cache performance even matters.

Secure delivery and TLS termination

The edge terminates TLS, validates hostnames, and can verify Signed URLs / Token Auth before serving from cache. That prevents unauthorized hot-linking of paid downloads or premium video segments. For some origins the CDN also re-establishes TLS upstream so the entire path remains encrypted.

WAF, rate limiting, and DDoS scrubbing

WAF rules inspect headers, methods, query strings, and behavioral signals. Volumetric floods are absorbed by the distributed edge surface, then scrubbed or rate-limited before they can saturate the origin region. Because the CDN already sits in front of user traffic, it is the natural place to centralize these controls.

Cache poisoning defenses

The cache key must be explicit. Do not accidentally vary on attacker-controlled headers or cache personalized responses under a public key. Normalize headers, constrain which query parameters affect caching, and never let untrusted upstream metadata silently broaden cache scope.

Origin protection

Origin endpoints should not be trivially reachable from the public internet, bypassing the CDN entirely. Authenticated CDN-to-origin paths, allowlisting, private connectivity, or mTLS (or equivalent mechanisms depending on the deployment) keep origin from being a plain, unguarded target.

TLS and certificate lifecycle

Certificates, keys, and TLS configuration must be safely distributed to every relevant PoP, rotated on schedule, and rolled back quickly if something goes wrong — without requiring a live central lookup on every handshake. This is control-plane work, described further in Architecture Deep Dive's Configuration and Certificate Distribution.

A CDN needs observability at three layers: request-path performance, cache effectiveness, and control-plane correctness.

Request-path performance

Track median and p99 latency by region, connection errors, TLS handshake timing, origin fetch latency, and large-object throughput. Regional dashboards matter because global averages hide geography-specific pain.

Cache effectiveness

Measure Cache Hit Ratio, byte hit ratio, origin offload %, shield hit ratio, revalidation rate, and top hot objects. A request hit ratio can look healthy while byte offload looks weak if large files are missing from cache frequently.

Control-plane health

Track config rollout lag, purge queue depth, purge propagation latency, cert deployment status, and routing convergence after route withdraws. When someone says 'the purge did not work,' you want precise timestamps per region, not guesswork.

Security visibility

Monitor WAF matches, rate-limit drops, bot scores, abnormal cache-key entropy, and spikes in origin bypass traffic. Those signals often catch attacks or misconfigurations before customers describe them as latency issues.

Metrics this design keeps distinct

Worth naming precisely rather than lumping together: request hit ratio vs byte hit ratio vs shield hit ratio, origin offload, p50/p95/p99 latency by region and PoP, cache fill/revalidation latency, origin error rate, stale-served rate, purge propagation lag, config rollout lag, route convergence/traffic-shift behavior, and per-tenant resource concentration (a noisy-neighbor indicator). Not every possible metric is worth tracking — these are the ones that connect directly back to the architectural decisions above.

The clearest way to explain a CDN is to evolve it live. Each stage exists because the previous one failed under a named pressure.

Stages 1–5 — single origin to first cache hits

1. Single Origin Server: everything comes from one machine. 2. Global Users Experience High Latency: distance dominates RTT. 3. Introducing Edge Locations: place reverse proxies near users. 4. Cache Miss Flow: edges pull from origin on first access. 5. Cache Hit Flow: repeated reads become local and fast.

Stages 6–10 — protecting the origin

6. Traffic Spike & Origin Overload: hot content makes too many misses expensive. 7. Regional Cache Layer: add a middle tier for better long-tail locality. 8. Origin Shielding: funnel edge misses through shield. 9. Cache Expiration Strategies: TTLs, revalidation, and stale-while-revalidate. 10. Cache Invalidation Challenges: purge becomes a distributed control-plane problem.

Stages 11–15 — correctness, dynamic paths, and routing maturity

11. Versioned Assets: immutable URLs reduce risky purge dependence. 12. Dynamic Content Problems: bypass or short-cache personalized responses. 13. Signed URLs & Secure Delivery: authorize protected assets at the edge. 14. Video & Large Asset Delivery: segment-based delivery and range requests make huge objects cache-friendly. 15. Anycast Routing: many PoPs announce the same IP so users land on the nearest healthy edge.

Stages 16–18 — production-scale operations

16. DDoS Protection & Edge Security: absorb and filter attack traffic close to ingress. 17. Multi-Region Failover: reroute around failed PoPs or origin regions. 18. Production-Scale CDN Architecture: globally distributed edge, shield layers, origin replicas, purge/control plane, and unified observability. Beyond Stage 18 — Control-Plane Scale and Blast Radius: once the fleet spans thousands of PoPs and configurations, safely distributing config, certs, and purge becomes a distributed-systems problem in its own right — separate from, and just as important as, serving bytes.

By the final stage, the CDN is a coordinated global system: edge delivery, shielded cache hierarchy, control-plane distribution, security enforcement, and multi-region origin resilience.

Two distinct planes

The finished architecture is easiest to reason about as two planes with very different jobs. The data plane carries every request: Client → DNS/Anycast/front door → Edge ingress/TLS/WAF → Edge RAM/SSD → Regional Shield → Origin LB/Origin Regions. The control plane carries every configuration or policy change: Customer/operator config → validation/versioning → metadata/config store → regional/fleet distributors → local edge snapshots.

Purge lives in the control plane, but lands in the data plane

Purge requests flow through the control plane's validation, versioning, and fan-out machinery, and the result is a state change applied locally at each edge — not a live query the data plane makes on every request.

Why this separation matters

The common request path is intentionally independent of the live central control plane. An edge serves from its last versioned local snapshot; it does not block on a central lookup to decide whether to serve a request. That is what lets the data plane stay fast and resilient even when the control plane itself is having a bad day.