Latency Budget Decomposition
Allocating a total response-time target across the components of a request path, so each layer has an explicit share and overruns are attributable.
A "500 ms p95" target is not actionable until it is divided. Decomposition turns it into constraints each team can design against and test against.
A worked example for a 500 ms budget: 50 ms network and TLS, 20 ms gateway and authentication, 100 ms service logic, 200 ms data access, 50 ms serialisation and response, leaving 80 ms of reserve.
What the exercise produces beyond the numbers:
Impossible targets are exposed immediately. If the round trip alone is 200 ms for the user population in question, a 200 ms budget cannot be met from a single region — a fact worth establishing before a quarter is spent optimising code.
Timeouts follow from it. Each layer's timeout should reflect its allocation plus margin, and timeouts must decrease inward, or an outer layer gives up while inner work continues.
The reserve is the important part. A budget allocated to 100% has no room for the variance that produces the tail, and will be met at p50 and missed at p95.
Re-derive it when the path changes: an added hop consumes someone's allocation, and the decomposition makes that explicit rather than a surprise.