Timeouts

The Default Is Failure

No timeout means “wait forever” — and forever is how one stalled dependency eats your service:

 payment provider slows to 30s per call (their incident)
 your service: no timeout set
 threads/workers block 30s each → pool exhausts in seconds
 NEW requests queue behind stuck workers → YOUR api now 503s
 health checks fail → orchestrator restarts → cold stampede
 
 ONE dependency's latency = YOUR outage.
 the missing timeout is the amplifier, not their slowness

Timeout Budgeting

 every request has a total budget, split across hops:

 user request budget: 1000ms
 ├─ auth check        20ms
 ├─ trip lookup       100ms   timeout: 150ms
 ├─ fare engine       200ms   timeout: 250ms
 └─ response write     10ms

 rules:
 - child timeout < remaining parent budget (never exceed)
 - leave slack for serialization/network overhead
 - budgets derive from SLOs, not guesses

A downstream timeout longer than your own deadline is a lie — you’ll abandon the work anyway; the timeout should say so.

Choosing Values

Signal	Approach
Measured p99.9 of healthy dep	Timeout ≈ p99.9 × small margin
No data yet	Start generous, tighten with observations
Interactive path	Tighter; fail fast beats hang
Background/async	Looser; correctness over latency

Timeouts too low cause failure amplification — you abort calls that would have succeeded, converting tail latency into errors. Tune from distribution data, not folklore.

What Happens on Timeout

 client side:  give up → error/fallback/cached value/retry policy
 server side:  THE REQUEST MAY STILL COMPLETE!
 
 timeout ≠ cancellation (own lesson: deadlines).
 fire-and-forget side effects continue: charge may still occur,
 row still written → design callers assuming "state unknown"
 → this is WHY idempotency keys exist alongside timeouts

The Timeout Inventory

Every place waits happen needs an explicit bound:

 HTTP client calls      connect + read timeouts, both set
 database drivers       query_timeout per statement
 cache clients          single-digit-ms reads; long = worse than miss
 message publishes      publish confirm window
 lock acquisitions      bounded wait or fail fast
 shutdown drains        SIGTERM grace period

Unbounded anything is the audit finding. Frameworks default to infinity more often than people expect.

Interview Framing

Design reviews probe: “what happens when the recommendations service hangs?” Scored answer: explicit timeout below request budget, fallback behavior defined (skip recs, not fail checkout), and the state-unknown caveat leading to idempotency. Candidates quoting “just add timeouts” without values/budget hierarchy show book knowledge only.