Z3 · Resilience & Reliability

Timeouts

Bronze

A timeout caps how long a caller waits for a dependency. Without one, a slow dependency ties up threads and connections until the caller fails too.

Use when: Every network call to a dependency
Avoid when: Never skip them — only the value changes
Trade-offs: Too short: false failures and extra retries. Too long: held resources and cascades · A timeout must fit inside the caller's own deadline
Requires: Failure modes & availability, Latency & percentiles

2 objectives · 5 misconceptions

choose Choose a timeout from a dependency's latency percentiles and the caller's own time budget.
diagnose Diagnose a cascading failure caused by missing timeouts.

Not true: Long timeouts are safer because fewer requests fail.
Not true: Library default timeouts are reasonable.
Not true: A timeout close to the dependency's typical (average or median) latency is about right.
Not true: When a slow dependency drags the caller down, the caller needs more servers.
Not true: While a dependency is slow, only the requests that call it are affected.

Learn

No katas practice this yet.

→Timeouts→