Origin Shield
A CDN has 300 PoPs. Each PoP independently caches content. On a cache miss, each PoP fetches from origin. For a popular asset that isn’t yet cached: 300 PoPs, each with a cache miss, all simultaneously fetching from origin. That’s 300 concurrent origin requests for one piece of content. Origin shield solves this: a second caching tier that sits between all edge PoPs and origin, collapsing those 300 origin fetches into one.
The Problem Without Shield#
Without origin shield: edge PoP in Tokyo gets a cache miss for /video/intro.mp4. It fetches from origin. Simultaneously, 50 other PoPs get the same miss and also fetch from origin. Your origin server handles 50 concurrent requests for the same object. On a viral content event, this overwhelms origin.
The thundering herd problem at CDN scale. Each edge PoP has its own cache, so misses in different PoPs are independent. There’s no coordination between them.
Origin Shield Architecture#
Origin shield designates one or a few regional “shield” PoPs per geography. Edge PoPs in a region send their cache misses to the regional shield PoP, not directly to origin. The shield PoP has its own cache. If the shield has the content, it serves it. If not, the shield fetches from origin — only once, regardless of how many edge PoPs asked simultaneously.
Request Collapsing#
Within a single PoP (shield or edge), request collapsing handles simultaneous misses for the same object. When 50 requests arrive for an uncached object simultaneously, only one fetch goes to the upstream (shield or origin). The other 49 wait for the first to complete, then all 50 are served from the newly cached response. This is a different mechanism from origin shield but addresses the same problem at finer granularity.
Trade-offs#
Origin shield adds latency on cache misses: instead of edge-to-origin (say, 80ms), the path is edge-to-shield-to-origin (say, 20ms + 60ms = 80ms, same) or worse if shield and origin are not geographically close. Shield placement should minimize the edge-to-shield + shield-to-origin latency sum.
Shield cache size matters: a shield with insufficient cache evicts content frequently, reducing its effectiveness. Shield PoPs are typically larger than edge PoPs: more storage, more memory.
At Oracle#
When Oracle Cloud Object Storage introduced CDN integration, we configured origin shield for the Asia-Pacific region: all APAC edge PoPs funnel misses through a Singapore shield. Pre-shield, a file uploaded to Object Storage and requested simultaneously from 20 APAC PoPs generated 20 origin requests in the first second. Post-shield, it generated 1. Peak origin request rate during a popular software release dropped 94% after enabling shield.
What I’m Learning#
Origin shield is a second cache tier that solves the thundering herd at CDN scale. The key insight: coordinate cache misses across geographically distributed edge PoPs by funneling them through a shared intermediate cache. Origin sees dramatically fewer requests; edge latency is almost unchanged because shield-to-origin latency is similar to direct edge-to-origin.
Have you configured or operated origin shield, and how much did it reduce origin load in practice?