Deadline Propagation
also called Deadline Budget, Request Deadline
Passing the remaining time budget down each call in a request chain so downstream services never work on a request whose caller has already given up.
Independent timeouts at each hop produce a specific waste that is invisible until you look for it. The gateway times out at 2 seconds; service A calls B with a 3-second timeout; B calls C with 5. When the request is slow, the gateway abandons it at 2 seconds and A, B and C keep working — consuming threads, connections and database time on an answer nobody will read. Under load this is exactly when capacity is scarcest, so the waste compounds the incident.
Deadline propagation replaces per-hop timeouts with a single budget set at the edge and carried through the call chain, usually as a header or in the RPC context. Each service computes its remaining time, passes the remainder onward, and fails fast if the budget is already exhausted rather than starting work.
The second-order benefits are what make it worth the plumbing. Retries become budget-aware, so a service does not retry when there is no time for the retry to help. Queued work can be dropped on dequeue if its deadline has passed, which is one of the most effective load-shedding mechanisms available. And the deadline is a natural place to distinguish "we were slow" from "the caller left".
The rule to enforce alongside it: a deadline must always shrink as it propagates, never be reset by a downstream service, which is a surprisingly common bug in service templates.