Free cookie consent management tool by TermsFeed Generator

Series: Asymptotically Ruined: Capacity Planning Beyond the Light-Tailed Assumption

The greatest paradox in distributed systems engineering is that our obsession with "simplicity" is the single most reliable generator of unmanageable complexity.
Capacity planning under heavy-tailed demand isn't harder than under light-tailed demand, it's structurally different, and this series proves exactly where that difference breaks a standard capacity number. It then builds what survives it: a physical-signal admission control loop, a multi-resource generalization checked against an independent Price-of-Anarchy result, an eviction rule derived as optimal stopping, and a fleet-pooling result sized by the same square-root staffing law used in queueing theory. Before recommending any of it, the series prices what the adaptive machinery itself costs to run, and closes with a decentralized-versus-centralized architecture comparison, translated into a concrete build order and on-call runbook.

7 posts in this series

  1. 1. The Newsvendor Problem Under a Heavy Tail

    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 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. This post proves it formally, for the whole class at once, not case by case.

    02 August 2026

  2. 2. The Phase MAPE-K Usually Skips

    No algorithm can save a Blood Oath workload: Post 1 proved that formally. What's left is physical, not algorithmic: a redline that watches real headroom and its derivative instead of trusting a number, an honest accounting of when autoscaling actually helps, and a buffer sized by the same critical-fractile logic that opened the series. None of it adapts on its own; that only starts once MAPE-K's own most commonly skipped phase, Knowledge, actually closes the loop the other four were never built to close by themselves.

    05 August 2026

  3. 3. Multi-Resource Capacity and the Price of Anarchy

    A margin computed at the wrong level of abstraction doesn't fail where the old threshold said it would: it fails a third of the way there. This post generalizes Post 2's single-resource redline to a genuinely multi-resource setting, finds the real byte-level exhaustion point sits at roughly a third of the slot-based Sedimentation Threshold, not at the threshold itself, and checks that finding against a structurally unrelated argument reaching the same qualitative warning from a different direction: Price of Anarchy, a nonlinear equilibrium-inefficiency metric that spikes near saturation in a real production system, not a second measurement of the same quantity.

    09 August 2026

  4. 4. Optimal Stopping at the Edge of a Limit Cycle

    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.

    12 August 2026

  5. 5. The Square Root That Doesn't Cover Routing

    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 checks whether scale changes what the earlier four posts prove is needed, 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. This post prices that specific tradeoff, and leaves the fuller comparison against a fully centralized alternative for the post built to make it.

    16 August 2026

  6. 6. The Meta-Constraint This Series Never Priced

    Five posts have priced, over and over, what it costs to guess wrong about a distribution that won't hold still: borrowing five of the Constraint Sequence Framework's six named components along the way, without ever turning the sixth, Meta-Constraint Awareness, on the machinery doing the pricing. This post runs that test on its own series: a real, three-times-computed numerator with a fourth entry named but never priced, a denominator no post has ever measured, and a Return on Investment whose sign comes out genuinely undetermined, not favorably assumed. The formula's own algebra still yields a real bound on how cheap that machinery has to be, and formal metareasoning research, cited directly, explains why the missing stopping criterion isn't an oversight: it's the same unsolvable regress that research already proved exists and resolved by capping it, not computing it. Then it points the same unpriced test at the next post's own proposal (centralizing the machinery itself) before that proposal gets to claim an advantage nobody has costed either.

    19 August 2026

  7. 7. Building What Six Posts Only Proved

    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.

    23 August 2026

← Back to all posts