Cache Hierarchy: L1, L2, and Origin Shield Explained

A CDN cache hierarchy is a multi-layered architecture where cached content is stored at progressively fewer, more centralized locations between end users and the origin server. Rather than every edge node independently fetching from the origin on a cache miss, a well-designed hierarchy routes misses through intermediate tiers that aggregate requests, absorb traffic spikes, and dramatically reduce the load on your infrastructure. Understanding how L1, L2, and origin shield tiers interact is essential for optimizing cache hit ratios and protecting origin servers at scale.

What Is a CDN Cache Hierarchy?

In a flat CDN architecture, every edge server independently contacts the origin when its local cache does not contain the requested resource. With 200 or more Points of Presence worldwide, this means a single piece of content could trigger 200 separate origin fetches, one from each PoP experiencing a cache miss. A cache hierarchy solves this by introducing intermediate layers that intercept cache misses before they reach the origin.

The standard hierarchy consists of three tiers:

• L1 (Edge Cache) — The outermost tier, closest to the end user. Each PoP maintains its own L1 cache.
• L2 (Regional/Mid-Tier Cache) — A smaller number of regional data centers that serve as parents to multiple L1 nodes.
• L3 (Origin Shield) — A single designated cache location that sits in front of the origin server, aggregating all remaining cache misses.

This layered approach transforms cache miss behavior from a fan-out problem into a funneling pattern where each tier catches more requests, and progressively fewer reach the origin. For an overview of how caching fits into the broader CDN picture, see our caching strategies guide.

How Does the L1 Edge Cache Work?

L1 caches are deployed at every edge server location in the CDN network. When a user requests a resource, the closest L1 node checks its local cache first. If the content is present and fresh according to its TTL configuration, the L1 node serves it directly with minimal latency, typically under 20 milliseconds.

L1 caches have specific characteristics that distinguish them from deeper tiers:

Because L1 nodes have limited storage and serve geographically localized traffic, their cache contains mostly popular content for that region. Long-tail content with low request frequency often misses at L1, which is where the L2 tier becomes critical.

What Role Does the L2 Regional Cache Play?

L2 caches sit in regional data centers, typically 10 to 30 locations globally. Each L2 node serves as a parent cache for a cluster of L1 edge nodes. When an L1 cache miss occurs, the request is routed to the parent L2 node rather than directly to the origin.

The L2 tier provides several advantages:

Aggregated cache population. Because an L2 node receives cache misses from multiple L1 nodes, it sees a larger slice of the total traffic pattern. Content that is infrequently requested at any single L1 node may be frequently requested across the entire L1 cluster that feeds into that L2. This aggregation effect significantly improves hit ratios for long-tail content.

Larger storage capacity. Regional data centers have more physical space and can deploy higher-capacity storage systems. A typical L2 node might cache 50 to 200 terabytes compared to 1 to 10 terabytes at L1, allowing it to retain a much larger working set of content.

Reduced inter-region traffic. Without L2, a cache miss at an L1 node in Tokyo would fetch directly from the origin in Virginia. With L2, the miss goes to a regional hub in Singapore, which likely already has the content cached. The shorter geographic distance reduces latency on cache misses and avoids expensive cross-continent bandwidth.

The routing between L1 and L2 is typically determined by consistent hashing based on the cache key. This ensures that requests for the same resource always route to the same L2 node, maximizing cache efficiency and preventing fragmentation across regional nodes.

How Does Origin Shield Protect Your Infrastructure?

Origin shield is a dedicated cache tier positioned directly in front of the origin server. All cache misses from L2 nodes must pass through the origin shield before reaching the origin. This creates a single chokepoint that consolidates all remaining cache misses from the entire CDN network.

Without origin shield, each L2 node independently fetches from the origin on a miss. With 20 L2 nodes, a newly published piece of content could generate 20 simultaneous origin fetches. With origin shield enabled, all 20 L2 misses route to the shield, which forwards only a single request to the origin and serves the response to all waiting L2 nodes.

Origin shield is particularly valuable in these scenarios:

• Origin servers with limited capacity — Small or medium origins that cannot handle burst traffic from cache misses across hundreds of PoPs.
• Expensive origin fetches — When the origin must perform computation, database queries, or API calls to generate responses, reducing fetch volume directly reduces cost.
• Cache invalidation events — After a cache purge, all PoPs simultaneously need fresh content. Origin shield absorbs this thundering herd by collapsing all requests into one.
• Long-tail content catalogs — Streaming services or e-commerce sites with millions of unique assets benefit from an additional cache layer with massive storage.

How Do Requests Flow Through the Cache Hierarchy?

Understanding the complete request flow through a multi-tier cache hierarchy clarifies how each tier contributes to performance and origin protection.

Step 1: L1 lookup. The user's request arrives at the nearest edge PoP. The L1 cache checks for a valid cached copy using the cache key. If found and within TTL, the response is served immediately. This is the fastest path, with round-trip times typically under 30 milliseconds.

Step 2: L2 lookup. On an L1 miss, the edge node routes the request to its parent L2 regional cache. The L2 node performs the same cache key lookup. If the content is found, the L2 serves it to the L1 node, which caches it locally for future requests and forwards it to the user.

Step 3: Origin shield lookup. If the L2 also misses, the request routes to the origin shield. The shield checks its own cache. Because the shield aggregates traffic from all L2 nodes globally, it maintains the highest hit ratio in the hierarchy, typically between 95 and 99 percent.

Step 4: Origin fetch. Only if all three tiers miss does the request reach the origin server. The origin generates the response, which then flows back through the hierarchy: origin shield caches it, forwards to L2, which caches and forwards to L1, which caches and serves to the user.

At each tier, Cache-Control headers determine how long the content is retained. Some operators configure tiered TTLs, where inner tiers cache content longer than outer tiers to keep warm copies closer to the origin.

What Is Request Collapsing and Why Does It Matter?

Request collapsing, also called request coalescing, is a critical optimization within cache hierarchies. When multiple requests for the same resource arrive simultaneously at a cache node that does not have the content, the node could forward each request independently to the next tier. This creates redundant work and amplifies load.

With request collapsing enabled, the cache node detects duplicate in-flight requests and holds them. Only the first request is forwarded to the parent tier or origin. When the response arrives, the node caches it and serves all waiting requests from that single response.

Request collapsing is especially important during these events:

• Cache stampedes — When a popular resource expires, hundreds of simultaneous requests discover the miss and all attempt to refetch. See our guide on cache stampede prevention for additional mitigation strategies.
• New content publication — A viral article or product launch generates immediate traffic to an uncached URL.
• Post-purge refetching — After invalidation, every edge needs the new version simultaneously.

Most CDN providers enable request collapsing by default at L2 and origin shield tiers. Some also support it at L1, though the smaller request volume at individual edge nodes makes it less impactful there.

How Do Major Providers Implement Cache Hierarchy?

Each CDN provider offers its own implementation of cache hierarchy, with different terminology and configuration options:

CloudFront Origin Shield is the most explicit implementation. You select a specific AWS region for the shield, ideally the region closest to your origin server. All cache misses from the 13 Regional Edge Cache locations funnel through the chosen shield region before reaching the origin. AWS recommends enabling it when your origin cannot handle high concurrency or when you want to maximize cross-region cache sharing.

Cloudflare Tiered Cache automatically organizes its 300+ PoPs into a hierarchy where lower-traffic edge nodes pull from higher-traffic hub nodes. With Argo Smart Routing enabled, Cloudflare dynamically selects the optimal mid-tier path based on real-time network conditions rather than static topology.

Fastly Shielding allows you to designate a specific PoP as the shield for each backend origin. All edge misses route through this shield PoP. Fastly recommends choosing the PoP geographically closest to your origin. Unlike CloudFront, Fastly does not have a separate L2 tier; its architecture goes from edge directly to shield.

How Should You Optimize Cache Fill Across Tiers?

Cache fill refers to the process of populating cache tiers with content. Optimizing cache fill reduces unnecessary data transfer, lowers costs, and improves the speed at which new content becomes available across the network.

Key optimization techniques include:

Consistent hashing for L2 routing. Ensure that requests for the same cache key always route to the same L2 node. This prevents the same content from being cached on multiple L2 nodes, wasting storage and increasing origin fetches. Most providers implement this automatically, but verify by checking if different L1 nodes hitting the same L2 region produce consistent X-Cache headers.

Tiered TTL configuration. Set longer TTLs at inner tiers than at outer tiers. For example, if L1 caches content for 5 minutes, configure L2 to cache for 30 minutes and origin shield for 2 hours. This keeps inner caches warm even as outer caches expire, reducing origin fetches during revalidation cycles.

Proactive cache warming. After deploying new content or performing cache invalidation, proactively warm the origin shield and L2 caches using cache warming techniques. This prevents the thundering herd effect when the first wave of user requests arrives.

Cache key normalization. Ensure cache keys are normalized consistently across tiers. If query parameter order varies between requests, each variation generates a separate cache entry. Normalizing keys at the edge prevents fragmentation that wastes capacity at every tier in the hierarchy.

When Should You Add More Cache Tiers?

Not every deployment needs three tiers. The right number of cache levels depends on your traffic patterns and origin capabilities:

• Single tier (L1 only) — Sufficient for small sites with limited geographic reach and origins that can handle moderate traffic. Simple to configure and debug.
• Two tiers (L1 + L2) — Appropriate for most production workloads. The L2 tier catches long-tail misses and reduces origin load by 80-90%. Most CDN providers enable this by default.
• Three tiers (L1 + L2 + Origin Shield) — Required for high-traffic sites with sensitive origins, large content catalogs, or workloads where origin fetch costs are significant. The incremental latency on cache misses is offset by dramatically higher overall hit ratios.

Monitor your performance metrics at each tier. If your L2 hit ratio is already above 95%, adding origin shield provides diminishing returns. If your origin is receiving more than a few hundred requests per second despite having L2 enabled, origin shield can reduce that to single digits.

A well-tuned cache hierarchy transforms CDN architecture from a simple edge cache into a sophisticated content distribution system. By understanding how L1, L2, and origin shield tiers interact, you can configure each layer to maximize hit ratios, minimize origin load, and deliver consistent performance to users regardless of where or when they access your content.