Origin Shield Offload Calculator

You’ve launched a site and the traffic is spiking. Your server is protected by an origin shield that sits between your database and your edge locations. When duplicate requests hits, the shield soaks them up so they don’t swamp your backend. How does it work? On paper, the math is easy. In reality, not so much. You must be able to model it.

The primary issue that shields solve is called “cache fanout.” Think about it: You’ve got forty-five edge servers spread across the globe. They’re all missing on the same popular image simultaneously. That means forty-five of them will hit your origin all at once with an identical request. Unless you have a shield in place to handle this, those requests will pile up, consuming both your capacity and bandwidth at the same time.

How Origin Shields Protect Your Website

When equipped with a shield, only one edge server hits the shield (and the shield hits the origin). The other edge servers grabs their copy from the shield instead. This collapses duplicate traffic and creates headroom in your infrastructure when unexpected bursts occur.

To get a sense whether this will work for you, don’t just rely on the hit ratio. To help you out, calculator above does all that math for you (no guesswork at coefficients needed) but it relies on you plugging in your own miss rates and population sizes. What those numbers say is something about how your architecture is designed.

How many edge points of presence do you have? You’d be surprised; more than you think matter. The more content you serve from the same content, the larger your potential fanout and thus the higher the percentage of requests you should see offloaded by any given shield layer. So if you run a small network with only five locations, shielding may not help much. But if you have fifty-plus globally, duplicate requests really start to add up.

Then there’s the matter of defining what a “hit” is. Is it a cache hit, where the object is found in the intermediate cache and avoids doing any work at the origin? Or is it a revalidation, where an object is cached but the server sends checks to see if it has been updated? This also touches the origin and thus counts against your request capacity. When designing for scale, you need to consider this overhead.

If your objects have a really short TTL, you’ll end up with a lot of revalidations that keep the origin loaded more than pure misses imply. So part of the trick here is knowing exactly what’s being counted: It’s not just the number of bytes you’re saving… It’s the amount of request load you’ve reduced.

Another is bandwidth. If your shield provides a cached response, then there’s never any traffic from your origin server to your shield or anywhere else. It saves bandwidth on that priciest connection. You can observe this by looking at capacity differences in the reference table on the page.

Static assets like JavaScript bundles or images are reused more often when they have longer times to live. Dynamic API responses may has shorter times to live, though you still gain from collapsing duplicate reads during peak hours. Consider surge events too. The traffic pattern of a launch day, viral post, or security incident will be nothing like your typical day.

You should of model a surge multiplier and understand whether your origin can breathe with the heat turned up. You only have fifteen percent headroom under a two-times traffic load. Then you’re probably going to run out before long. Most folks don’t realize this until they read an incident report. People plan for average load, but they forget that caching efficiency shifts during spikes due to increased key duplication and hotter keys.

At its core, this comes down to control. When traffic acts different than expected, you have a lever to pull. Your cache keys becomes standardized, and your freshness rules makes sense. Duplicate requests die at the regional level rather than reaching your main database.

Before deploying, you can use the calculator to check that your assumptions make sense. But it is more valuable during planning time. This forces you to describe how your definition of success affects your starting capacity. Do you really want to discover you’re vulnerable to fanout once the monitors start crying?

Installing a shield is simple. Knowing how much load you’re trying to deflect so you can tune it to protect your back end under attack, that’s hard.