Use finite connection and request timeouts, retry only plausibly transient failures on operations safe to repeat, and assign retry policy to one layer. Add capped exponential backoff with jitter, then stop at an attempt limit or the caller’s deadline. If the database remains impaired, reduce incoming work rather than continuing to send retries.
Why retries can make recovery harder
A retry is another request sent to a dependency that may already be slow or overloaded. If many callers retry together, that extra work can sustain high load after the original fault. A request that waits indefinitely can also tie up connections, threads, or other resources needed to make progress.
As an Amazon Associate I earn from qualifying purchases.
The aim is not to retry every failure. It is to give a short-lived fault a bounded chance to clear without letting waiting requests and repeat work overwhelm the database.
Set a finite time budget for the whole operation
Bound both connection establishment and request execution. Choose those timeouts using observed latency, the caller’s deadline, and the behavior of the specific database and client. A timeout that is too generous can hold resources while work stalls; one that is too short can interrupt a slow but successful operation and generate more traffic. Some framework defaults may be infinite or too high, so inspect the defaults rather than assuming they are safe.
#1 Best Overall
Include the original attempt, every retry wait, and each later attempt in one overall budget. Stop when the caller’s deadline is exhausted, even if the configured attempt limit has not been reached. A retry count limits how many attempts can occur; a deadline also limits how long the caller waits. Use both when they fit the application’s latency objective.
Decide which failures and operations are safe to retry
Classify failures against the client contract
Retry only errors that the database or client contract identifies as plausibly transient. Repeating authentication failures, invalid input, or configuration errors does not fix their cause. Check the driver, SDK, ORM, or database documentation for retryable error conditions and built-in behavior; the eligible set can vary by client and operation.
Rank #2
Protect writes against duplicate effects
A timed-out write can leave the caller unsure whether the database committed the first attempt. Before replaying a write, establish that it is idempotent—that repeating it has the same intended effect—or use an application-level idempotency mechanism. Do not assume that a timeout means the original operation did not happen.
Free tools Windows power users keep installed
One-click scans. No signup required.
Shape retries and put a firm stop on them
Use backoff with jitter
Increase the wait after successive failures, cap the maximum delay, and add a newly sampled random component to each wait. The increasing delay reduces the pace of repeat requests; jitter helps prevent callers that failed together from retrying in synchronized waves. Google IAM documents an example formula of min(2^n + random_fraction, maximum_backoff) with a deadline. Its example values are guidance for that API, not general database settings.
Bound attempts as well as delay
A delay cap alone does not stop a client from retrying forever at the capped interval. Set an attempt ceiling, an elapsed-time limit, or both, and make the overall deadline authoritative. When the budget is spent, return a failure or let the caller handle it; do not silently start another unbounded retry cycle.
Keep one layer responsible for retries
Choose a single retry owner and inspect retry behavior in the SDK, driver, ORM, proxy, and calling service. Policies at nested layers can multiply the total attempts: each layer may repeat work that an inner layer has already repeated. One owner makes the aggregate attempt budget easier to understand and prevents application retries from unknowingly stacking on client-library retries.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose the control that fits the failure
| Approach | Useful when | Trade-off |
|---|---|---|
| Bounded retries with backoff and jitter | A failure may be brief and the operation is safe to repeat. | Each retry still consumes capacity, so the policy needs a firm stop. |
| Fail fast when the budget is exhausted | The caller’s deadline is reached or the failure is not retryable. | The current request will not receive another attempt. |
| Circuit breaker | Repeated timeouts or failures indicate persistent impairment. | Calls are rejected while the breaker is open; thresholds, open duration, and recovery probes need system-specific design. |
| Load shedding | Incoming work, including retries, exceeds the system’s capacity. | Some requests are deliberately dropped to reduce pressure on the overloaded system. |
Use a circuit breaker for persistent impairment
A circuit breaker can stop calls after a threshold of failures or timeouts, return a fast failure while open, and later allow a recovery check. This matters for a slow database because repeated calls can consume database thread-pool resources and aggravate contention. The threshold, time spent open, and probe strategy depend on the system; there is no universal setting.
Include retries in overload controls
When incoming load exceeds capacity, load shedding can drop some requests—including retries—upstream of the overloaded system. Google SRE recommends exponential backoff with jitter for RPC retries to dampen error amplification. Pair traffic controls with monitoring of failure rates and retry behavior so operators can tell whether load is subsiding or impairment continues.
Implement and validate the policy in this order
- Inspect existing behavior. Identify timeouts and retry defaults in the database client and every layer between the caller and database.
- Set the caller’s overall deadline. Reserve time for the original attempt, retry waits, and later attempts; ensure every attempt ends within that budget.
- Define eligible failures and operations. Use the client’s documented retry conditions, and verify that replayed writes are idempotent or protected against duplicate effects.
- Configure one retry owner. Disable or account for overlapping policies so nested layers do not multiply attempts.
- Add capped exponential backoff with jitter. Set an attempt ceiling or elapsed-time limit in addition to the delay cap.
- Plan for continued impairment. Decide when to fail fast, open a circuit breaker, or shed load instead of sending more work to the database.
- Observe the combined behavior. Monitor failures and retries, and validate that the complete policy respects the caller’s latency budget and does not keep pressure elevated during recovery.
Why there is no universal timeout or retry count
The right settings depend on the database engine, client library, workload, transaction semantics, topology, observed latency, and caller’s latency objective. General guidance supports finite timeouts and bounded retries, but it does not establish one timeout value, retry count, error-code list, or circuit-breaker threshold for every database. Choose values from the actual system behavior, account for built-in retries, and validate the policy as a whole.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
