Work amplification under load

Why do timeouts convert latency into load, and how does deadline propagation stop it?

A timeout is a guess about a latency distribution, written into code before the incident, for a distribution that will not exist during the incident.

The general rule: timeouts convert latency into load. Every abandonment throws away partial work: the connection handshake, the TLS negotiation, the query plan, the partial scan, the state read. The retry redoes all of it. A system can be destroyed by a latency increase that never exceeded any component's capacity, purely through the cycle of abandon and redo.

The escape: make the timeout a property of the request

The escape is to make the timeout a property of the request and not of the hop. Deadline propagation passes the remaining time budget down the chain. A callee with 5 ms left refuses to start 50 ms of work. This turns wasted work into shed work: the same failure, but with 0% capacity cost instead of 100%.

gateway receives request at t=0 with deadline = t+300 ms
  -> booking gets "remaining: 290 ms"
    -> pricing gets "remaining: 240 ms"
      -> database gets "remaining: 200 ms"; if it is below the minimum work time, it replies "too late" at once

The cost is that deadlines are viral. Every hop, every client library and every queue must carry and respect the deadline. A single hop that drops it silently returns the whole chain to the broken behavior. This is a coupling cost paid in plumbing. It is the reason deadline propagation is common inside single-vendor RPC stacks and rare across organizational boundaries. Cancellation must propagate too: an abandoned request whose downstream work continues is the same waste with a different owner, which is why cancellation tokens and context propagation exist, and why "fire and forget" calls are a liability during incidents.