Timeout ⏱️ — Preventing Requests from Waiting Forever

A timeout defines how long a service should wait for a response from another service or resource. If the response does not arrive within that period, the request is stopped.

sequenceDiagram
    participant A as Service A
    participant B as Service B

    A->>B: Request
    Note over A: Wait for configured timeout

    B-->>A: Response
    Note over A: Success

1. Why Do We Need Timeouts?

Without a timeout, a slow or unavailable dependency can keep requests waiting and consume application resources.

flowchart LR
    A["Service A"] --> B["Slow Service B"]

    B --> W1["Waiting Request"]
    B --> W2["Waiting Request"]
    B --> W3["Waiting Request"]

    W1 --> X["Resources Exhausted"]
    W2 --> X
    W3 --> X

Timeouts prevent requests from waiting indefinitely and help protect threads, connections, memory, and other resources.

2. Basic Timeout Flow

sequenceDiagram
    participant A as Service A
    participant B as Service B

    A->>B: Request
    Note over A,B: B does not respond

    A-->>A: Timeout
    A->>A: Return Error / Fallback

3. Types of Timeouts

• Connection Timeout — maximum time to establish a connection.
• Request Timeout — maximum time allowed for the complete operation.
• Read Timeout — maximum time waiting for data from a connection.
• Idle Timeout — maximum period a connection can remain inactive.

4. Timeout in Microservices

flowchart LR
    A["Order Service"] --> T["Timeout"]
    T --> P["Payment Service"]

    P --> D["Slow Dependency"]

    T --> F["Failure / Fallback"]

For example, if the payment service does not respond within the configured timeout, the order service should not wait indefinitely.

5. Timeout + Retry

A timeout can trigger a retry when the failure is potentially transient. However, retries must also have limits.

flowchart LR
    R["Request"] --> T["Timeout"]

    T --> R1["Retry 1"]
    R1 --> T2["Timeout"]
    T2 --> R2["Retry 2"]

    R2 --> S["Success"]
    R2 --> F["Final Failure"]

Excessive retries can increase load on an already struggling service, so timeout and retry policies should be designed together.

6. Timeout + Circuit Breaker

flowchart LR
    A["Service A"] --> T["Timeout"]
    T --> CB["Circuit Breaker"]
    CB --> B["Service B"]

    B --> X["Slow / Failing"]

    CB --> F["Fast Failure"]

Repeated timeouts can contribute to the circuit breaker opening, preventing further calls to the unhealthy dependency.

7. Timeout Budget

In a chain of services, the total request deadline must be considered.

flowchart LR
    C["Client"] --> A["API"]
    A --> B["Order Service"]
    B --> P["Payment Service"]
    P --> D["Database"]

If the client has a total deadline of 5 seconds, every downstream call cannot independently wait for 5 seconds. Otherwise, the overall request could exceed the client's deadline.

8. Timeout Should Be Explicit

A good distributed system defines timeouts for external and internal network calls instead of relying on indefinite waits.

flowchart LR
    R["Request"] --> T["Configured Timeout"]

    T -->|"Response in Time"| S["Success"]
    T -->|"No Response"| F["Failure / Fallback"]

Important Interview Questions

• What is a timeout?
• Why are timeouts important in distributed systems?
• What happens if a downstream service is slow?
• Connection timeout vs request timeout?
• What is a read timeout?
• How do timeout and retry work together?
• How does timeout work with Circuit Breaker?
• What is a timeout budget?
• How would you choose a timeout value?
• Why can an unlimited timeout cause cascading failures?

Key Takeaways

• Timeout prevents a request from waiting indefinitely.
• Different operations can require different timeout types.
• Timeouts protect application resources.
• Timeout and retry should be designed together.
• Circuit Breaker can stop repeated calls after failures.
• Distributed request chains should consider an overall timeout budget.

Conclusion

For interviews, remember: Request → Wait Within Deadline → Success or Timeout → Recover / Fail Fast.