What is the Timeout pattern and how does it prevent cascading failures?

The Timeout pattern sets an upper bound on how long a caller will wait for a response from a downstream service. Without timeouts, a slow or unresponsive service causes the calling service's request-handling threads to block indefinitely. When enough threads are blocked, the caller's thread pool is exhausted, and it can no longer serve any incoming requests — the failure cascades upstream.

There are two distinct timeout types to configure on every HTTP/gRPC client:

• Connection timeout — the maximum time allowed to establish the TCP connection (and TLS handshake) to the server. If the server is unreachable or overloaded, the OS may queue the SYN packet indefinitely. A connection timeout of 1–3 seconds is typical for internal services.
• Read (socket/response) timeout — the maximum time to wait for the server to send its response after the connection is established. This covers the time the server spends processing the request. Set this to slightly above the service's P99 latency under normal load.

For asynchronous operations, a deadline (a fixed wall-clock time that the entire operation must complete by) is preferable to a per-hop timeout, because per-hop timeouts can accumulate across a call chain without any single hop exceeding its budget yet the total chain still exceeding the end-user SLA.

Timeout values must be tuned carefully. A timeout that is too short causes unnecessary failures during legitimate traffic spikes; too long defeats the purpose by allowing thread exhaustion before the timeout fires. Use the service's P99 latency measurements as the baseline and add a safety margin (e.g., P99 + 50%).

The Timeout pattern works best in combination with the Circuit Breaker (Q25): once timeouts accumulate and the failure rate crosses the circuit breaker threshold, the circuit opens and stops further timeouts from occurring, protecting the thread pool proactively.