CDN System Request Lifecycle Visualization

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

Represents the user or application context requesting web resources. Issues HTTP requests and measures latency, cache statuses, and errors. In the demo, watch request particles start at the browser and trace the latency metrics on the client panel.

Anycast / GeoDNS Routing

To resolve client queries and steer traffic to the most appropriate Edge POP. Maps user locations to nearest nodes or distributes traffic across IP address groups using latency and health checks. In the demo, watch how routing resolves client traffic and redirects to healthy nodes.

Primary and Alternate Edge POPs

Distributed caches located near user populations to serve content with minimal latency. Perform cache lookups, normalize keys, verify Cache-Control headers, and serve hits or handle misses. In the demo, watch edge POPs return green particles on hits, or redirect misses to L2 shield.

L2 Origin Shield

A mid-tier cache shared by multiple edges to consolidate misses and protect the origin. Aggregates edge misses, coalesces duplicate requests, and queries the origin only once. In the demo, watch edge misses coalesce at the shield before fetching from origin.

Origin Server

The central database and file server hosting the primary source data. Processes writes, generates responses, validates headers (ETag/Last-Modified), and issues Cache-Control directives. In the demo, watch origin fetches trigger and check database validator responses.

Purge Control Plane and Observability

To manage cache invalidation across the distributed network and monitor system performance. Distributes purge requests to all nodes to clear outdated files. Monitors hit ratios and latency. In the demo, watch purge commands propagate across edge/shield grids during purge events.

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.