CDN Edge Caching Simulator
Simulate a CDN with multiple edge PoPs, an origin shield, and an origin server. Watch cache hits, misses, SWR revalidations
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 globally distributed network of proxy servers designed to host static and dynamic content close to users. When a client requests an asset, directing the request to a central origin server across the globe introduces significant network latency and threatens origin stability under heavy traffic.
The core mental model is hierarchical caching. Request paths begin at regional User pools, route to nearby Edge PoPs (Points of Presence) to serve content immediately on a cache hit. On a cache miss, requests move to a shared centralized Origin Shield cache rather than hitting the origin directly. Only when both Edge and Shield caches miss does the request reach the Origin Server. Managing this hierarchy requires balancing latency and freshness using policies like TTL and Stale-While-Revalidate (SWR).
Components and Why They Exist
User Regions
Represent clients from different geographic areas (e.g., US East, Europe, Asia, S. America) generating content requests. Send request streams to the geographically closest Edge PoP. In the demo, watch request particles leave regional users and note their travel times to the nearest edge cache.
Edge PoPs (Points of Presence)
Distributed caches positioned close to users to satisfy reads with minimal network round-trip latency. Serve cache hits from local memory using an LRU eviction policy, and forward cache misses to the Origin Shield. In the demo, observe the visual cache slot grids inside each PoP node turning green (fresh hits) or orange (stale/revalidating).
Origin Shield
A centralized mid-tier cache shared by all Edge PoPs to absorb and consolidate edge cache misses. Satisfies edge misses, reducing redundant concurrent hits reaching the origin from multiple geographic regions. In the demo, watch edge cache misses stream into the shield and note how many are absorbed before reaching the origin server.
Origin Server
The source of truth database and application server hosting the original files. Generates authoritative assets, serves cold requests when caches miss, and handles background revalidation flushes. In the demo, watch origin fetch spikes when edge and shield caches are purged, or when TTL expiration waves occur.
Edge Cases and Misconceptions
- Origin Shield vs. Edge Caching: A common misconception is that Edge PoPs talk directly to the origin. Under high global traffic, direct misses from dozens of global edge nodes would overwhelm the origin. The Origin Shield coordinates and deduplicates these misses.
- SWR Stale Read Window: While Stale-While-Revalidate (SWR) guarantees low latency by serving expired cached files instantly, it means clients will temporarily receive stale data. If absolute consistency is required (e.g., banking or inventory), SWR cannot be used.
- Purge Thundering Herd: Purging a global CDN cache is necessary after major content updates, but it is dangerous. Clearing all cache slots simultaneously triggers a cold-start where all subsequent requests must hit the origin, causing a thundering herd crash.
- Cardinality and Cache Eviction: If an application serves a massive catalog of unique content (high cardinality) with uniform popularity, the working set will exceed the PoP capacity, causing continuous cache evictions and reducing the hit ratio to near zero.
Common Questions
How does an Origin Shield differ from standard Edge PoP caching?
Edge PoPs are distributed close to users globally. An Origin Shield is a centralized mid-tier cache positioned between the Edge PoPs and the Origin Server. Instead of all Edge PoPs querying the origin on a cache miss, they query the Origin Shield, consolidating misses and protecting the Origin Server from redundant requests.
What are the trade-offs of the Stale-While-Revalidate (SWR) cache policy?
SWR allows the cache to serve an expired (stale) resource to the client immediately while asynchronously fetching a fresh copy from the origin in the background. This provides near-zero latency for the client, but means the user receives stale content for that request.
How does content popularity distribution (key skew) affect CDN cache efficiency?
CDNs benefit from Zipfian or skewed traffic where a small percentage of keys (e.g. 10%) receive the vast majority of traffic (e.g. 90%). High skew results in high cache hit ratios even with small cache capacities. If key access is uniform (low skew), cache hit ratios drop significantly, putting heavy load on the origin.
What is a cache thundering herd and how does it happen during a purge?
A thundering herd (or cache stampede) occurs when cache keys are invalidated or purged simultaneously. Subsequent requests for those keys all miss the cache at once, sending a massive wave of concurrent requests to the Origin Server, which can cause resource saturation and outages.
Why does reducing TTL increase origin load, and how do we balance it?
Time-to-Live (TTL) defines how long content remains fresh. A shorter TTL keeps content more up-to-date, but forces the CDN to revalidate with the origin more frequently, increasing origin traffic. Balancing it involves using long TTLs combined with active cache invalidation (purging) upon updates, or using SWR.