System Design advanced LIVE DEMO
🌐

CDN System Request Lifecycle Visualization

Explore an 18-step CDN walkthrough covering Anycast and GeoDNS routing, cache keys, cacheability, request coalescing, validators, stale serving, failover, purge propagation

CDNAnycastGeoDNSEdge CacheOrigin ShieldCache-ControlETagFailover
Interactive Demo

Continue with the guided workspace

Use the paired workspace to connect this guide's mental model with live component state, visible signals, and the outcome each step or scenario is meant to prove.

Mental Model

A Content Delivery Network (CDN) is a critical component of web scale architectures. CDNs sit between users and application origins, serving as a distributed cache and routing layer to reduce latency, save bandwidth, and protect central origins.

The core mental model is a hierarchical request lifecycle. When a client requests content, DNS routing (Anycast or GeoDNS) steers them to the most appropriate Edge POP (Point of Presence). The edge POP checks its local cache. On a miss, the request goes to a shared centralized L2 Origin Shield rather than hitting the Origin Server directly. This visualizes a multi-tiered pipeline where request coalescing, cache-control directives (like max-age and SWR), and conditional validation headers (like ETags) cooperate to keep origin server load low while serving user content efficiently.

For sandbox parameter tuning, you can also use the retained CDN simulator.

Components and Why They Exist

Browser Client

The browser client represents the user or application context requesting web resources. It issues HTTP requests and measures end-to-end latency, cache statuses, and error responses. Request particles originate at the browser card while the client panel tracks round-trip latency and cache status headers.

Anycast / GeoDNS Routing

The Anycast and GeoDNS routing layer resolves client queries and steers traffic to the most appropriate Edge POP. It maps user locations to the nearest healthy nodes and redistributes traffic using latency and health-check signals. During an edge outage step, the routing node automatically shifts incoming client requests over to the healthy alternate POP.

Primary and Alternate Edge POPs

The primary and alternate Edge POPs are distributed caches located near user populations to serve content with minimal latency. Each POP performs cache lookups, normalizes cache keys, verifies Cache-Control headers, and either serves hits locally or forwards misses upstream. Cache hits return green response particles directly from the POP, while misses continue upstream toward the L2 shield.

L2 Origin Shield

The L2 Origin Shield is a mid-tier cache shared by multiple edges to consolidate misses and protect the origin. It aggregates edge misses, coalesces duplicate concurrent requests for the same key, and queries the origin only once. Concurrent misses arriving from both edge POPs collapse at the shield card so only a single fetch continues to the origin.

Origin Server

The origin server is the central application and storage tier hosting the primary source data. It processes writes, generates authoritative responses, validates conditional headers (ETag and Last-Modified), and attaches Cache-Control directives. Cold misses and conditional revalidation checks reach the origin card, which responds with either a full payload or a lightweight 304 Not Modified status.

Purge Control Plane and Observability

The purge control plane and observability pipeline manage cache invalidation across the distributed network while tracking system health. The control plane distributes purge requests to all edge and shield nodes to clear outdated objects, while telemetry monitors hit ratios and latency. When an invalidation is triggered, purge particles fan out from the control plane to clear cached slots across both the shield and edge POPs.

Edge Cases and Misconceptions

  • A CDN Is Not Just a Cache: It combines routing, caching, shielding, invalidation, and monitoring. Treating it as a single cache hides the failure modes that happen between tiers.
  • Cache Hits Can Still Be Incorrect: A response can be fast and wrong if the cache key ignores an important variation such as authorization, locale, device, or content negotiation.
  • Stale Serving Is a Bounded Policy: Stale-while-revalidate and stale-if-error are deliberate availability choices with limits. They are not permission to serve old content forever.
  • Purge Is Not Instant Everywhere: Distributed invalidation has propagation windows. Versioned URLs and controlled warming can reduce risk during the mixed-state period.

Common Questions

How does Anycast or GeoDNS choose an edge POP?

Anycast gets the request into nearby CDN infrastructure, while GeoDNS or traffic steering chooses an edge using latency, geography, capacity, and health signals. A healthy nearby POP is preferred, but health propagation delay can temporarily route users to a colder alternate edge.

Why can a cache hit still be wrong?

A cache hit is only correct when the cache key includes the inputs that change the response, such as authorization, locale, device type, cookies, or accepted image format. A key that is too broad can serve one user's or variant's response to the wrong request.

How does Origin Shield prevent an origin stampede?

Origin Shield sits between many edge POPs and the origin. When many edges miss the same object, the shield can coalesce those misses so one upstream origin fetch fills many waiting requests.

What is the role of request coalescing in CDNs?

Request coalescing (or collapse) combines multiple concurrent misses for the same object at the edge or shield layer into a single upstream request to the origin, keeping the origin from being overwhelmed by duplicate queries.

What is stale-while-revalidate?

Stale-while-revalidate lets a cache serve an expired response quickly while it refreshes the object in the background, trading short-lived staleness for lower latency and better availability.

Why do CDNs use ETag validators?

ETags support conditional requests. A 304 Not Modified response renews freshness without retransmitting the cached response body.

What is negative caching?

Negative caching stores selected error responses, such as a cacheable 404, for a short time so repeated requests for missing content do not repeatedly reach the origin.

Why is purge propagation risky?

A purge is distributed work, not one instant global switch. During propagation, some tiers may be empty while others still hold older objects, and a broad purge can turn normal traffic into simultaneous origin misses unless versioned URLs, shielding, and warming are planned.