Content Delivery Networks

A Content Delivery Network is a distributed system of servers, positioned at many network locations, that stores replicas of an origin's content and serves client requests from the replica expected to be fastest, cheapest, or most reliable to reach. The core resource is a set of edge servers organized into points of presence (PoPs), each holding a partial, dynamically maintained copy of the origin's data. The system's job is replica placement (deciding what content lives where) and request routing / server selection (deciding, for each client request, which replica should answer it). Two architectural patterns dominate. In a pull (reactive) CDN, edge servers start empty; on a cache miss they fetch the object from the origin (or a parent cache) and store it with a time-to-live, serving subsequent requests locally until eviction or expiry — this is the model used by general-purpose web CDNs. In a push (proactive) CDN, the origin explicitly distributes content to edges ahead of demand, typical for video-on-demand catalogs or software release artifacts where access patterns are predictable. Most production CDNs are hybrids: popular, predictable content is pushed or pre-warmed; the long tail is pulled on demand. Server selection — telling a client which edge to use — is solved chiefly by two mechanisms layered on infrastructure the client already trusts: DNS-based redirection, where the CDN's authoritative name servers return different edge IP addresses depending on which resolver asked (a technique built directly on DNS: The Internet Naming System), and anycast routing, where many edge servers share one IP address and BGP naturally routes each packet to the topologically nearest instance. A third mechanism, HTTP redirection or request routing at the application layer, lets an edge server that received a request (e.g., via anycast) issue a 302 redirect or internally proxy to a better-suited edge, refining a coarse first hop.

Step 1 — Content ingestion and placement. The origin (or CDN control plane) decides which objects are candidates for replication and which PoPs should hold them. This is driven by a cost model that trades off storage at each PoP, bandwidth to fill/refresh caches, and expected latency reduction for demand originating near that PoP.

Step 2 — DNS-based direction to a PoP. When a client resolves `www.example.com`, the origin's DNS delegates the CDN's hostname (`cdn.example.com`, often via a CNAME) to the CDN's own authoritative DNS. That authoritative server, upon seeing the query arrive from a particular recursive resolver, treats the resolver's IP (or, with EDNS Client Subnet, the client's approximate subnet) as a location hint and returns the IP address of a nearby, healthy, non-overloaded edge cluster.

Step 3 — Anycast (alternative/complementary path). Many CDNs additionally advertise the same IP prefix from every PoP via BGP. Routers along the path forward packets toward whichever PoP is topologically closest according to normal Internet routing — no per-client decision by the CDN is needed; the routing fabric itself performs the selection.

Step 4 — Request arrives at an edge server. The edge checks its local cache. On a hit, it serves the object directly (fastest path). On a miss, it may: (a) fetch from a regional/mid-tier cache (a shared parent serving a whole metro area or country), (b) fetch from the origin directly, or (c) proxy to a better edge if it discovers, via internal signaling, that a sibling holds the object.

Step 5 — Cache population and eviction. The fetched object is stored with metadata (TTL, `ETag`, `Cache-Control` directives from HTTP). Subsequent requests within the TTL are served locally. When storage fills, an eviction policy (commonly LRU, or frequency-aware variants) removes the least useful objects.

Step 6 — Health and load feedback. PoP health, load, and link congestion feed back into the DNS/routing layer continuously, so a client mid-session (or a fresh client moments later) is steered away from an overloaded or down PoP. ```pseudocode // ---- DNS-based CDN redirection (authoritative server logic) ---- function RESOLVE(query, resolverIP): clientLocation = ESTIMATE_LOCATION(resolverIP) // geo-IP or EDNS Client Subnet candidates = POPS_SERVING(query.hostname) // PoPs hosting this customer's content candidates = FILTER_HEALTHY(candidates) // drop PoPs failing health checks if candidates is empty: return ORIGIN_IP // fail open to origin best = argmin_{p in candidates} COST(p, clientLocation) return best.publicIP function COST(pop, clientLocation): // weighted combination; weights tuned by the operator return w1 NETWORK_LATENCY_ESTIMATE(pop, clientLocation) + w2 CURRENT_LOAD(pop) + w3 (1 if pop.linkCongested else 0) PENALTY // ---- Edge server request handling (pull CDN) ---- function HANDLE_REQUEST(req, edge): key = CACHE_KEY(req.url, req.headers) // vary-aware key entry = edge.cache.LOOKUP(key) if entry != null and NOT_EXPIRED(entry): edge.cache.TOUCH(key) // update recency for LRU return entry.response // cache HIT // cache MISS: fetch through the hierarchy parent = NEAREST_PARENT_CACHE(edge) response = null if parent != null: response = FETCH(parent, req) // may itself hit/miss recursively if response == null or response.status >= 500: response = FETCH(ORIGIN, req) // fall through to origin if IS_CACHEABLE(response): // honors Cache-Control, status code STORE(edge.cache, key, response, TTL(response)) if edge.cache.SIZE() > edge.cache.CAPACITY: EVICT(edge.cache) // e.g., LRU return response function EVICT(cache): victim = cache.LEAST_RECENTLY_USED() cache.REMOVE(victim) ```

Redirection cost. DNS-based server selection adds at most one extra DNS round trip compared to resolving the origin directly, since the CDN's authoritative answer is returned in the same recursive-resolution chain: $O(1)$ additional lookups, amortized further because resolvers cache the answer for the record's TTL. Anycast adds zero extra round trips — routing convergence happens once, at BGP timescales, not per request.

Cache lookup. Using a hash table keyed by URL (and `Vary` headers), lookup, insertion, and LRU-touch are each $O(1)$ expected time; eviction with a doubly linked list + hash map (classic LRU) is $O(1)$ per operation. Space is $O(C)$ where $C$ is edge cache capacity in objects/bytes, independent of total catalog size — this is the whole point: an edge need not store everything, only what is locally popular.

Why caching close to users reduces latency — a simple bound. Let $d_{oc}$ be the round-trip time from client to origin and $d_{ec}$ from client to nearest edge, with $d_{ec} \ll d_{oc}$ by construction (edges are provisioned in many metros; the origin is in one or few). On a cache hit, response time is $\approx d_{ec} + S$ where $S$ is service time; on a miss served through an edge that must still fetch from origin, response time is $\approx d_{ec} + d_{eo} + S$, which is still no worse than direct origin access when $d_{ec} + d_{eo} \le d_{oc}$ — true whenever the edge–origin path is at least partly shared or better peered than the raw client–origin path, which CDN backbone design guarantees. Expected latency is

where $p$ is the cache hit ratio. As $p \to 1$, latency $\to d_{ec} + S \ll d_{oc} + S$. This is why maximizing hit ratio (via good placement, sizing, and TTL policy) is the central performance lever, not merely "add more PoPs."

Replica placement as facility location. Choosing which of $k$ candidate PoPs should host a replica, to minimize expected weighted latency across demand points, is an instance of the k-median / facility location problem, known to be NP-hard in general. CDNs solve it in practice with:

• greedy/heuristic placement based on observed demand and cost gradients (place where marginal latency reduction per byte replicated is highest),
• LFU/LRU-driven organic caching (letting the pull model discover popularity locally, an approximation to the offline optimum with no coordination overhead),
• hierarchical caching (regional tiers absorb misses so no single edge needs the full catalog, trading one extra hop for large storage savings).

No CDN claims global optimality; the guarantee offered is closer to "no worse than direct origin fetch, usually far better," backed by continuous monitoring rather than a static proof.

Correctness of DNS-based redirection — an invariant. The essential invariant a CDN's authoritative DNS must preserve is: every IP address returned must currently be serving valid content for the requested hostname, and be reachable/healthy at return time. Health checks and short TTLs on CDN records (often 20–300 seconds, far shorter than typical DNS TTLs) let the system maintain this invariant despite PoP failures, because a stale answer is only usable for a bounded window before resolvers must re-query.

A known imprecision, honestly stated. DNS-based selection uses the resolver's address as a proxy for the client's location. When a client uses a distant public resolver (rather than its ISP's local one), this proxy is wrong, and the CDN may direct the client to a suboptimal PoP — a real, measured problem in production networks. EDNS Client Subnet (ECS) mitigates this by letting the resolver forward a client subnet hint, at some cost to resolver-side caching efficiency (answers become less shareable across clients) and privacy.

A client in Mumbai requests `https://cdn.news-example.com/photo/breaking.jpg`. Assume three CDN PoPs: Mumbai (M), Singapore (S), and Frankfurt (F), and an origin in Virginia (O). Round-trip times from the client:

Trace of events:

This trace shows the essential asymmetry a CDN exploits: the first request per region pays a hierarchy-traversal cost close to (or briefly exceeding) direct-origin latency, but every subsequent request within the TTL — potentially millions — pays only the local edge RTT. The hit ratio $p$ from the complexity section, for a viral photo, rapidly approaches 1, and the amortized average latency across all requesters collapses toward $d_{ec} + S \approx 8\text{–}15$ ms instead of 230 ms.

The CDN concept grew directly out of the 1990s realization that the web's centralized origin model would not scale to mass audiences — a problem crystallized by the 1994 "Slashdot effect" and repeated outages of popular sites under sudden load. The founding commercial CDN, launched from MIT research on distributed hashing and consistent hashing for content placement, showed that algorithmic replica placement (not just brute-force server duplication) was the key to scaling the web.

Virtually every large web property — news, e-commerce, social media, software distribution, and streaming video — relies on a CDN layer between users and origin infrastructure. Video-on-demand and live streaming services depend on CDN edge caching to deliver adaptive-bitrate segments without saturating a single data center's egress. Software and OS updates (patches, container images, app-store downloads) are pushed through CDN networks to avoid overwhelming vendor origins during synchronized global release windows. API gateways and even dynamic, personalized content increasingly sit behind CDN edge compute platforms that run short application logic (routing, authentication, A/B testing) at the PoP itself, shrinking round trips further. Because CDN edges already absorb enormous, bursty legitimate traffic, they are naturally positioned to absorb illegitimate traffic too: the same distributed capacity, health-check-driven routing, and anycast fan-out that smooths a viral traffic spike also dilutes and filters a volumetric denial-of-service flood before it ever reaches the origin. This dual role — performance delivery and traffic-absorbing perimeter — is why CDNs are the natural staging ground for the mitigation techniques covered in DDoS Attacks and Mitigation.

Ask the tutor: How would you design a cache-invalidation strategy for a CDN serving a news site where articles can be corrected minutes after publication?