Performance Budget for Backends
A latency or resource allowance allocated per component of a request path, so that the end-to-end target is composed rather than hoped for.
An end-to-end target of 300 ms at p99 is not actionable by any individual team. Decomposing it into allowances — 20 ms at the gateway, 50 ms for authentication, 120 ms for the primary service, 80 ms for the datastore, 30 ms of network and serialisation — gives each owner a number they can test against and defend.
The arithmetic that must be respected when composing it: latencies add along a serial path, and the end-to-end p99 is worse than the sum of component p99s, because the slow events are not perfectly correlated. Budgeting by adding p99s produces a target that will be missed, which is why serious budgets are set against a lower percentile per component or include explicit slack.
The enforcement that makes it real is automated: a performance test in the pipeline that fails when a component exceeds its allowance, so a regression is attributed to the change that caused it rather than discovered as a gradual drift six months later that nobody can bisect.
The organisational value is at least as large as the technical one. When a new feature requires an extra downstream call, the budget makes the cost explicit and forces a decision — remove something, parallelise, cache, or renegotiate the target — instead of the latency quietly increasing until a customer complains. That conversation is the whole point.