Retries, Timeouts, and Circuit Breakers: When to Use Each

Use a timeout to limit how long a request may wait, a retry to repeat a failed request that may succeed on another attempt, and a circuit breaker to stop calls to a dependency that is failing persistently. They address different parts of a failure: timeouts bound waiting, retries handle temporary faults, and breakers limit repeated pressure while a service recovers.

What Each Pattern Does

These patterns are often discussed together because distributed systems fail in ways that are delayed, intermittent, or difficult to distinguish from a successful operation. A server can be slow, a network connection can drop, or a downstream service can be unavailable. The patterns provide different controls rather than interchangeable fixes.

• Timeout: sets a maximum wait for an operation. When the limit is reached, the caller stops waiting and treats the attempt as failed or unknown.
• Retry: makes another attempt after a failure, usually with a limited count and a delay between attempts.
• Circuit breaker: tracks failures and temporarily rejects or redirects calls after a threshold is reached, instead of continuing to send requests to an unhealthy dependency.

A timeout does not necessarily stop work already running on the remote server. It may only stop the caller from waiting. Similarly, a failed response does not always mean an operation did not happen: the server may have completed a write but lost the response on the way back.

Start With Timeouts

Set timeouts for network calls and other operations that could otherwise wait indefinitely. Without a bound, a slow dependency can leave requests, threads, connections, or other resources occupied. As the number of waiting operations grows, a service that was merely slow can contribute to wider congestion.

Choose a timeout based on the operation’s expected latency, the caller’s overall deadline, and how much time remains for useful work. A user-facing request with a short end-to-end deadline should not spend most of that budget waiting for one downstream call. A background task may be able to wait longer, but it still benefits from a defined limit.

Where requests pass through several services, propagate a deadline or remaining time when possible. Otherwise, each layer may wait for its full independent timeout, causing the total duration to exceed what the original caller can tolerate. Consider separate connection, request, and overall-operation timeouts where the client library supports them; they measure different phases.

Retry Only Failures That May Be Temporary

Retry when a failure is plausibly transient and repeating the operation is safe. Examples can include a brief connection interruption, a temporary service-unavailable response, or a request that fails before reaching the server. A retry is less useful for a permanent validation error, an authorization failure, or a request that will predictably fail until its inputs or configuration change.

Use a small, bounded number of attempts. Add a delay between attempts, commonly increasing the delay after successive failures, and use jitter—random variation in that delay—to reduce the chance that many clients retry in sync. The retry schedule must fit inside the caller’s deadline; retries that continue after the result is no longer useful waste resources.

Before retrying a write, consider whether it is idempotent: repeating it should not create an unintended second effect. Reading a record is often naturally repeatable; charging a payment or creating an order may not be. For non-idempotent operations, use an API-supported idempotency key or another deduplication mechanism where available. If the outcome is uncertain, check the operation’s status rather than blindly repeating it.

Use Circuit Breakers for Persistent Failures

A circuit breaker is useful when a dependency’s failures or latency are sustained enough that continuing to call it is likely to waste resources or make recovery harder. The breaker observes calls and changes state based on configured conditions. In the open state it rejects calls quickly or invokes a fallback. After a waiting period, it may allow a limited number of test calls in a half-open state; success can close the breaker, while further failure can open it again.

Breakers are especially relevant for services with many callers or dependencies where repeated slow calls can consume a shared pool of threads or connections. They can reduce unnecessary traffic and help keep an outage from cascading. They do not repair the failing service, guarantee that a fallback is correct, or replace timeouts: a breaker needs bounded calls to gather meaningful results and avoid probes hanging indefinitely.

Configure thresholds and recovery behavior with care. A very sensitive breaker can reject calls during a harmless burst of errors; a sluggish one may react only after resources are already depleted. Monitor breaker state, failure rates, and latency, and make sure rejected requests produce a clear, appropriate outcome.

How to Combine Them

A common approach is to place a timeout around each attempt, allow only a few retries for eligible failures, and use a circuit breaker to stop repeated calls when failures persist. The exact order and implementation depend on the client library and service architecture, but the overall deadline must cover the entire retry sequence.

1. Define how long the caller can wait for the full operation.
2. Set a per-attempt timeout that fits within that deadline.
3. Identify which errors are transient and which operations can safely be repeated.
4. Limit attempts and use backoff with jitter, stopping when the deadline is near.
5. Use a breaker when persistent dependency failures justify temporarily rejecting calls, and define what the caller should receive while it is open.

For example, suppose an application requests a product record from a service that occasionally has brief network interruptions. A short per-attempt timeout prevents a stalled call from waiting forever; one or two delayed retries may recover from a transient interruption. If the product service remains unavailable, a breaker can stop every incoming request from repeatedly waiting on it. The application might show a cached record or a clear temporary-unavailable message, depending on the product’s requirements.

Common Mistakes and Trade-Offs

• Retrying everything: repeats permanent failures and can multiply load during an outage.
• Retrying at every layer: nested retries can create far more attempts than intended. Assign retry responsibility deliberately and account for retries made by libraries or proxies.
• Using long timeouts as a recovery strategy: this keeps callers waiting and can tie up resources; it does not make the dependency healthier.
• Treating a timeout as proof of failure: the server may have completed the operation even though the response did not arrive.
• Adding a breaker without a useful fallback: quick rejection may protect capacity, but it can still leave users with an unclear or unsuitable result.

Retries can increase load precisely when a struggling service has the least capacity. A timeout can make an operation’s outcome ambiguous. A breaker improves isolation but may temporarily reject calls that would have succeeded. These are deliberate trade-offs; use metrics and logs to understand attempts, latency, timeout rates, breaker transitions, and final outcomes.

Frequently Asked Questions

Should I use retries or a circuit breaker?
Use retries for a small number of plausibly temporary failures when repeating the operation is safe. Use a circuit breaker to limit calls during persistent failures. Many systems use both, along with timeouts.

Do retries need a timeout?
Yes. Bound each attempt and the full operation. Otherwise, a retry sequence can wait indefinitely or exceed the time the result is useful.

Can I retry a request after a timeout?
Only if repeating it is safe or the server can deduplicate it. A timeout means the caller did not receive a result; it does not prove the server did no work.

How many retries should I allow?
There is no universal count. Keep attempts bounded, fit them within the overall deadline, and measure whether retries improve success without adding harmful load.

Does a circuit breaker replace a timeout?
No. A breaker reacts to observed failures and can stop later calls, while a timeout bounds how long an individual call waits. Use timeouts even when a breaker is present.

Related

• Mouse on Console Games: No Switch 2 Needed
• Pokemon Names for Dogs: 100+ Real Ideas
• Must Use Samsung Routines? What You Need to Know