Pass the Remaining Budget Down, Not a Fresh One

There are two ways to express a deadline on the wire, and the choice is a clock question. An absolute deadline (deadline = 2026-08-25T10:00:02.500Z) is precise and composes trivially — every hop compares it with its own clock. It also requires every machine in the chain to agree on what time it is, and they do not: a receiver whose clock is 400ms fast concludes the request has already expired and rejects work that had most of its budget left. The failure is silent, load-independent, and appears as an unexplained error rate on one host.

A relative remaining duration (timeout: 1700ms) needs no clock agreement at all. Each hop starts its own monotonic timer on receipt and subtracts its own elapsed time before passing the remainder down. This is why gRPC puts a relative grpc-timeout on the wire rather than a timestamp, and it is the right default for the same reason.

The cost of relative encoding is that the transit time from caller to callee is invisible: the callee starts counting when it receives, so the budget it believes it has is larger than the real remaining time by one network hop. Over four hops with 5ms links, the leaf over-estimates by roughly 20ms. That over-estimate is in the safe direction — you occasionally do a little work whose result arrives too late, rather than refusing work that would have made it. Subtract a transit allowance at each hop if you want the number to be tight.

Note also that a relative deadline must be re-derived from a monotonic clock, never from wall time. A wall clock that steps backwards during an NTP correction can hand a request more budget than it started with; one that steps forward expires everything in flight. This is Never Measure a Duration With the Wall Clock in its most operationally expensive form.

Propagation is an all-or-nothing property along a path. One service that does not read the incoming deadline restores its own default for itself *and everything below it* — the budget is not merely lost at that hop, it is reset. A chain with nine correct services and one forgetful one has the failure behaviour of a chain with no propagation at all beneath that point.

The places it is most often lost are the boundaries where the request stops being a request. A queue: publishing to a broker and consuming later almost never carries the deadline, and the consumer may pick the message up long after it expired. A thread-pool handoff: the context lives in a thread-local or an async-local, and dispatching to a worker without copying it drops the budget. A language or protocol boundary: an HTTP call from a gRPC service, a Lambda invocation, an FFI call — anywhere the header has to be manually restated. A cache or proxy layer that reconstructs the request rather than forwarding it.

This makes deadline propagation an infrastructure concern rather than an application one. It belongs in the client library, the server interceptor and the framework middleware, so that the default behaviour of any new service is correct and the effort is in opting out. Systems that ask each team to remember it have propagation in roughly the services that were written by people who had read this lesson.

The signature of a dropped deadline is worth memorising because it is unmistakable: a latency histogram with a spike at exactly the default timeout value. A dense band at 30.0s means a hop is waiting its default, not its budget.

The reason to build this plumbing is not tidiness. A propagated budget converts several guesses into decisions, and all of them happen at the bottom of the stack where the capacity actually is.

A database that receives a 300ms budget can set a statement timeout, refuse a plan it estimates at 4 seconds, and choose a cheaper plan when the expensive one cannot finish in time. A worker dequeuing a job can drop it in a comparison rather than executing it for a requester who left. A cache can decide that a recompute cannot finish inside the budget and serve stale instead — the decision at the heart of One Key Expires and Five Hundred Instances Miss at the Same Millisecond. A service can pick a degraded, cheaper code path when its budget is thin rather than failing at full cost.

There is a second-order effect worth naming: because expired work is dropped, load falls fastest exactly when the system is most overloaded. As queues grow, more requests expire before being dequeued, so more are dropped for free, which drains the queue. Deadline propagation gives a system a natural negative feedback against overload, and it is the reason a budgeted system tends to degrade rather than collapse.

The honest limit: propagation tells a service how long its answer will be *useful*, not whether anyone is still waiting. Knowing the caller has gone requires The Caller Is Gone — Stopping Is Usually Right and Sometimes Unsafe, which is a separate mechanism with its own delivery problems.