Timeout Budget
also called Deadline Propagation
Assigning a request an overall deadline at the edge and passing the remaining time down each hop, so no service works on something already out of time.
Independently configured per-hop timeouts do not compose. Four services each with a "sensible" 30-second timeout produce a two-minute worst case, long after the client gave up.
A deadline fixes this: the edge sets one (say 3 seconds), each hop passes the remaining budget onward, and any service that cannot complete within what remains fails immediately rather than starting work whose result will be discarded. gRPC supports this natively; over HTTP it is a header by convention.
Two properties this gives you. Work is not wasted on abandoned requests, which is a meaningful capacity saving under stress. And retry logic becomes coherent: a retry is only worth attempting if enough budget remains for it to succeed, which prevents the retry storms that fixed attempt counts produce.
Set per-hop timeouts from the observed tail rather than round numbers — a timeout well above p99 does not protect anything, and one below p95 turns normal slowness into errors.