When a system is overloaded, the standard advice is "shed load." Netflix's sharper question: whose load? Because dropping the request that started a movie and the request guessing what you'll watch next are not the same decision.
Under stress, most systems treat every request identically — first-come-first-served, or worse, drop at random. So when latency spiked, Netflix's playback availability fell for everyone equally: the user who just hit play suffered the same odds as a background prefetch the app fired speculatively. That's egalitarian, and it's exactly wrong.
Load shedding means deliberately dropping some requests when you can't handle them all — better to cleanly reject a few than to collapse under all of them. The usual implementation drops indiscriminately.
But your requests aren't all worth the same. "The user just pressed play" is sacred — fail it and a human is staring at a spinner. "Prefetch the next episode in case they keep watching" is a nicety — fail it and almost nobody notices. Shedding both at the same rate spends your scarce capacity on guesses while real users wait.
The expensive non-answer
One way to protect critical traffic is to physically separate it — run prefetch on its own cluster so it can never crowd out playback. Netflix considered this and balked: standing up and maintaining duplicate, isolated clusters for every priority tier is enormously costly. They wanted prioritisation without the hardware bill of physical sharding.
The solution: a priority-aware load shedder inside PlayAPI, built on the same concurrency-limits machinery as their adaptive limits work. Requests are tagged by priority — user-initiated vs. prefetch — and the limiter partitions capacity so that when it must shed, it sheds the low-priority traffic first. Critical requests get protected headroom; speculative ones absorb the damage. All on shared infrastructure.
The proof came from a real incident. Netflix saw a 12x spike in prefetch requests per second from Android devices — a flood that, under the old uniform scheme, would have degraded playback for the entire user base. Instead, prioritised shedding held user-initiated availability above 99.4% while letting prefetch availability sink as low as 20%. The speculative traffic took the hit so real viewers never felt it.
Worth knowing
The 20% figure isn't a failure — it's the system working. Prefetch is speculative; degrading it under load is precisely the trade you want. The mistake engineers make is treating all degradation as bad. Healthy systems degrade deliberately, sacrificing the least valuable work first. A flat availability number hides whether you're failing the right requests.
The gap it reveals
"Shed load under overload" is the textbook line. The senior realisation is that load shedding without prioritisation can protect your infrastructure while still failing your users — because it drops critical and trivial requests alike. Knowing to tag requests by business value, and to shed cheapest-first on shared capacity rather than buying isolated clusters, is the judgment that separates resilience from mere survival.
In the interview room
If your design includes prefetching, caching warmups, or background jobs sharing a path with user requests, expect: "what gets dropped first when you're overloaded?" A candidate who answers "I'd prioritise user-initiated traffic and shed speculative work first, on shared infra to avoid duplicate clusters" has just demonstrated they think about graceful degradation as a design dimension, not an afterthought.
The reframe
Reliability isn't a single number you push toward 100%. It's a set of choices about what to sacrifice first when you can't have everything. Netflix's win was recognising that their requests had wildly different value, and that the cheapest, most robust protection was to teach one shared system to tell them apart — not to build a fortress around the important ones.
Don't ask how to drop less load. Ask which load you can afford to drop.
Primary source →
netflixtechblog — Keeping Netflix Reliable Using Prioritized Load Shedding