Timeouts

The Default Is a Lie

 unconfigured timeouts default to OS/framework values:
   connect: 75s+ (some stacks), read: infinite or minutes

 a service calling 3 dependencies with defaults:
 one hung dependency = worker threads pile up for MINUTES
 → thread pool exhausts → YOUR service hangs too.

 [users]──►[api]──►[recommendations]  (hung, no timeout)
              ▲ threads accumulate here
              └─ in 60s: all workers stuck → api down too

 NO TIMEOUT = every downstream hang becomes YOUR outage.

The Timeout Budget Chain

 work BACKWARD from what users can tolerate:

 user patience:            1000ms total for this endpoint
   ├─ auth check:          ≤ 50ms   timeout 100ms
   ├─ db query:            ≤ 200ms  timeout 300ms  
   ├─ recommendations:     nice-to-have → timeout 150ms,
   │                       fallback on expiry ✓
   └─ margin/slack:        remaining

 RULES:
 □ parent timeout > sum of child timeouts (or cancel-on-parent)
 □ each hop SHRINKS its children's allowance — never equal
 □ budget documented per call path; reviewed like code

Timeout Hygiene Checklist

 □ EVERY network call has explicit connect + read timeouts.
   grep your codebase right now; find the missing ones.
 □ DEADLINE PROPAGATION: pass remaining-budget downstream
   (grpc deadlines, http headers); skip work that can't finish:
     parent deadline 200ms left, child needs 500ms?
     don't even start it — fail fast to fallback ✓
 □ RETRY-INTERACTION: retries live INSIDE the timeout:
     total_budget ≥ attempts × (timeout + backoff)
   classic bug: 3 retries × 5s timeout under 4s budget =
   guaranteed failure + wasted load. arithmetic, not vibes.
 □ TIMEOUTS ARE SLIs TOO: timeout-rate spikes = dependency
   sickness signal; alert before full outage.

Choosing Values

Signal	Guidance
Dependency p99.9	set slightly above it
User-facing budget	hard ceiling; everything fits beneath
Batch/offline calls	generous, but NEVER unlimited
Interactive vs async	interactive tight; async generous

 anti-patterns:
 ✗ one global timeout value everywhere (budgets differ!)
 ✗ timeout == p50 of dependency (guarantees tail failures)
 ✗ "we'll tune later" (later is an incident)

Interview Framing

“Service occasionally hangs when recommendation service degrades” scored diagnosis: missing/oversized timeouts as root cause, budget-chain arithmetic drawn from user-facing latency backward, deadline propagation proposed, retry-within-timeout math shown, timeout-metrics alerting added. The sentence worth saying verbatim: “every network call gets an explicit timeout — no exceptions, checked in review.”