After a bursting tenant is bounded on a shared cluster, why is the contention only capped and charged rather than removed?

## Fairness levers against isolation The distinction that this whole question turns on: **an isolation lever gives an owner resources nobody else can touch; a fairness lever only bounds how much of a common pool one owner may take.** While the nodes stay shared, everything available is the second kind. Bounding a bursting tenant does not hand the quiet tenant a reserved share — it lowers the worst case the quiet tenant can be subjected to. That is genuinely valuable, and it is not the same as making the neighbour's performance independent of what everyone else does. The practical consequence is a **floor below which contention cannot be driven while the hardware is shared**. You can bound it, and you can decide whose problem it becomes, but you cannot make it zero from inside the cluster. ## Where the cost went A bound does not delete work; it relocates the pain onto a named owner. | | Before the bound | After the bound | |---|---|---| | Bursting tenant | Finishes on time; sees nothing wrong | Progresses more slowly; its own unsent work accumulates | | Quiet neighbours | Slower answers, timeouts, an incident | A bounded worst case, not a guarantee | | The operator | An unattributed slowdown | A deliberate, attributable cost borne by a specific team | That relocation is the point, and it is also why the decision is not purely technical. Somebody's throughput was deliberately reduced. If that owner was not told, you have converted a shared incident into an unexplained one for them, and they will open their own. ## Second-order effects a senior answer should predict 1. **The deferred burst.** Work that could not be sent does not evaporate; it queues on the bounded owner's side. When its allowance is relaxed, or when its batch window finally opens, the same volume arrives compressed into a shorter interval. 2. **Retry amplification.** Depending on the platform, an owner over its allowance may be answered more slowly or refused outright. A refused client retries, which raises its request rate — so part of the cost you pushed onto the bounded tenant returns to the shared nodes as extra requests. This is the most common way a bound makes things worse in the first minutes. 3. **A slow answer is indistinguishable from a sick cluster.** From the bounded tenant's own monitoring, deliberately delayed answers look exactly like a degrading broker. Unless the bound is communicated, that team diagnoses a platform failure. 4. **Downstream backlog.** A slowed writer becomes a growing backlog somewhere — its own pipeline, its upstream source, or a caller that is now waiting. The cost usually surfaces in a system that is not the broker at all. ## The residual contention no setting reaches - Bounds are typically expressed on one or two axes. An owner held to a byte rate can still be expensive in request rate or in how long its requests occupy handler threads. - Memory, cache and disk remain common. A burst that displaced what neighbours were reading cheaply keeps costing them after the burst is bounded. - Platforms differ in which axes they let you bound at all, and rented offerings may expose fewer of them than a cluster you run — so the reachable floor is partly a property of what you are operating. ## Where the shared-hardware lever runs out There is a recognisable end state: the bound strict enough to protect the neighbours is too strict for the bounded team to meet its own obligations. At that point the conversation stops being about levers and becomes a question about the estate — whether these workloads should be on the same machines at all. That call has its own owners, its own cost model and its own failure modes, and the correct move here is to hand it over rather than to pre-empt it. Recognising the boundary precisely is much of what separates a senior answer from a confident one. ## What a defensible response carries - An **attributed** cause, because a bound applied to the wrong owner is just a second incident. - An **announced** bound, so the affected team reads its slowdown correctly rather than as a platform fault. - An **owner** who has accepted the cost, because the bound is a decision about someone's throughput. - A **measurement** that the neighbours actually recovered, since bounding the wrong axis produces no improvement and looks, from the totals, exactly like bounding the right one. - An **expectation** of the deferred burst, so the relaxation is planned rather than discovered.