You cannot defend by doing more work

Why must every overload defence lose work on purpose, and which three things can it change?

You cannot defend against overload by doing more work

The earlier articles were diagnoses. This article is the treatment, and it has exactly one principle: you cannot defend against overload by doing more work. Every mechanism here does less: less work, worse work, or work for fewer people. No defence preserves full service, because the premise of overload is that full service is not available.

So the design question is not whether to lose work, but which work, when, and who decides. This is the discard principle, now as the rule of the whole article:

Control theory makes the list short. A loop has gain, delay and a store (where excess accumulates). Every defence attacks one of the three:

• Reduce gain: budgets, breakers, brownout.
• Reduce delay: fast detection, local decisions.
• Bound the store: queue limits, concurrency limits, deadlines.

Nothing else is available. That is why the list of defences is short and keeps coming back.

Bounding the store: shedding, admission and backpressure

The store is bounded at the edge and inside. Admission control and load shedding refuse the excess before it costs anything: shed early and a rejected request costs about 0; shed late, by timeout, and it costs a full service, which is congestion collapse. Backpressure moves the store to the producer. It works only where the producer can slow down and the signal reaches the origin, so it is the tool inside your boundary, and shedding is the tool at it.

One interaction bites. Backpressure plus a persistent broker moves the store instead of removing it. Kafka will absorb an enormous backlog happily, which is a feature, but you have turned a latency problem into a retention problem, and the failure shows up later as consumer lag and the recovery arithmetic. Costs are conserved.

AIMD: the damping law

AIMD (additive increase, multiplicative decrease) is the rule TCP uses, and the one that ended congestion collapse: when things go well, increase the sending rate or limit by a small fixed step; when there is a sign of trouble, cut it by a fraction (for example halve it). It generalizes backoff, because it is a continuous controller, and many of the defences here are AIMD in disguise (adaptive concurrency limits are the clearest case). The decrease must be multiplicative, because a fixed-rate response meets exponential growth and loses. And it is asymmetric, increasing slowly and decreasing fast, because the cost of overshooting is larger than the cost of undershooting.