A proof tells you a mechanism is correct under stated conditions. It doesn't say what component owns the check, what it costs to run, or what order to build six of them in when a real system needs more than one at once. This post is that build: one engineering answer per problem this series proved, six runbook entries for what on-call actually does when each one fires, and the dependency order that keeps them from being built against each other. Then it turns to the choice every mechanism in this series made without ever arguing for it: decide locally, on a stale view. Checked against seven real points in the centralization design space, not two, from Google's Borg to a production LLM-serving system that arrived at this series' own routing algorithm independently, with a decision tree for finding the right one fast and honest pros and cons for reading past it: real vendor claims kept separate, throughout, from what's actually been verified.
Every post in this series so far has priced one pool, one resource, one task's decision. Real fleets run hundreds of pools at once, and this post answers whether volume changes what the earlier four prove necessary, not by assumption, but by an exact classical queueing result precise enough to price a real number: how many gigabytes pooling a fleet's own memory margin actually frees, and exactly where that pooling stops working. It also opens a question its own routing mechanism begs and never argues for: why push-based sampling, when a design that removes staleness by construction instead of sampling around it already exists: prices that specific tradeoff, and names the fuller comparison against a fully centralized alternative as the job of the post built for it.
Post 3 cited a paper this series can't quietly set aside: threshold-based eviction, proven dynamically unstable under saturated demand, a worst-case limit cycle that costs up to half of throughput. This post takes on the population Blood Oath was built to exclude from that result (tasks that can actually be evicted) and asks the two questions Post 3 left open: is a single eviction worth its cost, and is running that rule as a policy, at scale, safe from the instability Post 3 only watched from the outside. It also checks a third: would a fleet-wide coordinator make a better call than the local rule this post proves optimal on its own terms: and the answer splits in two, one physical reason coordination can't help the ranking decision itself, and one real, unpriced reason it still might help pace evictions across nodes sharing the same fabric.
The newsvendor problem is seventy years old, closed-form, and taught in the first weeks of any operations course: cheap to solve right up until the tail gets heavy. This post proves precisely where that seventy-year-old stability ends, then finds the one workload shape where even the correctly-computed answer isn't enough: cost unknowable until completion, no preemption, no horizontal escape. No scheduling algorithm can save it (not a cleverer one, not a centralized one with a perfect view of every node) and this post proves both formally.