Timeout
A timeout limits how long a caller waits for a response. It describes the state of the caller and does not prove by itself a failure of the remote operation.
- Time budgetMaximum caller waiting time.
- UnresolvedA late response is not a failure.
- Trade-offShort: many open. Long: waiting time.
Context
Why this is important
A caller cannot wait forever, but an expired wait says nothing about the remote operation. Without this distinction, the shop reports an error, although the payment has succeeded. Partial failure and Idempotence deepen their own building blocks.
This building block explains time budget and uncertain call output. Retry handles permissible follow-up attempts; partial failure classifies incomplete flows.
At a glance · Time limits the waiting time
Choose the payment time budget
The order module passes an authorization to the payment module that calls up the external provider. The shop time budget ends after one second; the provider response arrives later.
This is how you read the picture
- Time budget Slider with 250, 1000 and 3000 ms; 1000 ms is the payment time budget.
- Unresolved The display 'status unresolved' counts responses that arrive after the time budget.
- Trade-off Interplay of 'answered in time', 'status unresolved' and 'longest wait' when adjusting.
- answered in time
- 13 of 16
- status unresolved
- 3
- longest wait
- 1 s
Payment time budget: most responses arrive in time, few stay unresolved, and the wait remains acceptable for the customer.
Response times illustrative
Benefits & limitations
Helps if:
- An agreed response target bounds how long request paths occupy connections and workers.
- Multi-stage distributed workflows need a propagated overall budget for all sub-operations.
Boundaries
- Limits that are too short interrupt valid but slow operations; compare them with measured latencies and adjust them after changes.
- After 1,000 ms, whether the provider processed P-731 remains unknown; resolve the outcome using its identifier rather than a blind Retry.
- Inner calls receive at most the time remaining until the outer deadline. Cancellation must be propagated and supported so that downstream work can stop after the deadline expires.
In practice
- Define the measurement point. State whether the limit covers connection establishment, the start of a response or complete processing. Check that the protocol, client and measurement cover the same interval. This creates a clear timeout definition for comparison with runtime data.
- Derive the overall deadline. Derive the expiry time from the response target and give each downstream operation only the remaining time. Also define how expired work is signalled or tracked at the business level. This bounds total duration without starting a new budget for each service.
- Test cancellation and outcomes. Investigate which components actually stop ongoing work and which may continue after a timeout. Define status queries and resumption for the latter. This gives you reliable handling of resources and uncertain business outcomes.
Read the detailed explanation
A timeout defines the maximum waiting time for a specific step. Connection establishment, the start of a response and complete processing may have separate limits. A composite process propagates a deadline so downstream steps use only the remaining budget. This complements decisions about Synchronous communication and possible Retry attempts.
A timeout initially describes what the caller observes. It confirms neither cancellation at the recipient nor reversal of an effect already stored. Cancellation signals help only if the participating components support them. Otherwise, the business process needs an unresolved state and later status resolution. Choose the limit using user needs and measured latency, rather than an isolated default value.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
How many of the 16 responses are unresolved at 250 ms?
View the solution with justification
13 of 16: only 3 responses arrive within 250 ms.
ApplyingTransferred to a new situation
The shop should have as few unresolved cases as possible for the payment of B-1042, but wait at most one second. Which budget?
View the solution with justification
1000 ms: 13 of 16 responses arrive in time, 3 remain unresolved. These are treated as 'payment being clarified'.
EvaluateWeighing an alternative
The team raises the budget to 3000 ms. What speaks for it, what speaks against it, and what do you recommend?
View the solution with justification
Advantage: only 2 unresolved cases. Disadvantage: the customer waits up to 3 s and threads stay bound longer. Recommendation: keep 1000 ms and clarify unresolved cases cleanly.
Explore further
These building blocks continue the thoughts of this page.
References
- AWS – Timeouts, retries, and backoff with jitter (opens in new tab)Explains timeouts, limited repetitions, and jitter based on distributed failures.
- gRPC – Deadlines (opens in new tab)Explains time budgets and their distribution along a call chain.
- Google SRE – Handling Overload (opens in new tab)Explains the link between overload, queues and limited resources.