# Retries, backoff and jitter > Retries give an operation another chance after a temporary failure. Exponential backoff spaces attempts farther apart, and jitter randomizes their timing so clients do not overwhelm a recovering service together. A good design also limits retries and prevents repeated attempts from duplicating side effects. Source: https://sysround.com/concepts/retries-backoff Updated: 2026-11-05 ## How retries, backoff and jitter works First decide whether the failure is retryable. Connection failures, throttling responses, and selected server errors may be temporary; invalid input and permission failures usually are not. A timeout means the outcome is unknown, not that the server did nothing. Make repeated attempts safe before enabling them. Reads are often safe to retry, but operations such as charging a card need a stable idempotency key and server-side deduplication. Reuse the same key across attempts for the same logical operation. Use capped exponential backoff. For retry number n, starting at zero, compute cap_n = min(max_delay, base_delay × 2^n). With a 100 ms base and a 2-second maximum, successive delay caps are 100, 200, 400, 800, 1,600, and 2,000 ms. Add jitter to spread attempts over time. With full jitter, choose each delay uniformly between zero and that attempt's cap. For example, clients facing a 400 ms cap might wait 57 ms, 231 ms, and 386 ms rather than all retrying after exactly 400 ms. Bound the policy with per-attempt timeouts, a maximum number of attempts, and an overall deadline. Before scheduling another attempt, check whether enough time remains for useful work. Honor a valid Retry-After instruction when applicable; if it exceeds the deadline, stop or defer the operation rather than retrying early. Control retries across the system, not just per request. Choose one retry-owning layer where possible, enforce a shared retry budget, and limit concurrency. For background work, persist the next-attempt time in a queue or scheduler instead of holding a worker asleep; send exhausted work to an explicit failure or reconciliation path. ## Worked example: Retrying notification delivery during a provider outage Suppose 10,000 notification jobs encounter a provider outage. Configure at most five total attempts per job, a 500 ms base delay, a 30-second cap, and full jitter. The four retry windows are 0–500 ms, 0–1 second, 0–2 seconds, and 0–4 seconds; these are delays between attempts, not absolute execution times. Workers persist each next-attempt time and release the job rather than sleeping. A provider-wide limiter allows at most 200 outbound attempts per second, including retries, so jitter is not the only load control. Every attempt reuses the notification's idempotency key if the provider supports it. After exhaustion, retain the job for investigation; an ambiguous timeout may require checking provider status before another send. ## Trade-offs - **Better recovery, higher latency.** Retries can hide brief failures, but unsuccessful attempts and waiting consume the caller's latency budget. - **Extra load during failures.** Retries add traffic when a dependency may already be overloaded, so attempt limits need aggregate retry budgets and admission control. - **Less synchronization, variable timing.** Jitter reduces synchronized retry bursts but makes individual completion times less predictable. - **Duplicate side effects.** An earlier attempt may succeed after the caller times out, so safe retries require idempotency, deduplication, or outcome reconciliation. - **Compounding across layers.** If three nested layers each allow three total attempts, one user request can produce up to 27 calls to the deepest dependency. - **Durable recovery costs.** Background retries survive process failures only if attempt counts, scheduling state, and operation identity are stored durably. ## When to use it in a system design interview - A service calls an external payment, email, SMS, or other provider that can time out or throttle requests. - Queue workers must recover from temporary processing failures without immediately redelivering the same work in a tight loop. - Many clients or agents may reconnect after the same outage, deployment, or network interruption. - An ingestion pipeline must drain accumulated work after an outage without overwhelming downstream storage. - A durable workflow must continue across transient failures while preserving an explicit deadline and terminal failure state. ## How to bring it up in the interview - Define retryable outcomes and operation safety before naming the algorithm; expect the interviewer to ask what happens if the first attempt succeeded but its response was lost. - State a concrete policy: base delay, maximum delay, jitter method, total attempts, per-attempt timeout, and overall deadline. Explain that the values come from the latency target and dependency behavior. - Name the retry-owning layer and check SDK, proxy, and worker defaults; interviewers often probe how nested retries multiply downstream load. - Explain overload protection separately: jitter spreads retries, while retry budgets, concurrency limits, and circuit breakers bound or stop them. - Describe the exhausted-retry path and observability: track original requests versus retry attempts, success after retry, deadline exhaustion, and the age of delayed work. ## Common mistakes - Retrying every error, including permanent validation failures or unsafe writes without idempotency. - Using exponential backoff without jitter, leaving clients synchronized after a shared failure. - Setting a maximum delay but no attempt limit or deadline, allowing retries to continue indefinitely. - Assuming jitter limits total traffic; a large client population can still overwhelm a dependency at the capped delay. - Treating retry exhaustion as proof that an operation failed, even though an earlier timed-out attempt may have completed. ## Interview questions where it comes up - [Design a notification system](https://sysround.com/questions/design-notification-system): Provider failures require bounded, jittered retries, duplicate-send protection, and an explicit exhausted-retry path. - [Design a distributed message queue like RabbitMQ](https://sysround.com/questions/design-message-queue): Delayed redelivery and retry limits are central to preventing retry storms and handling poison messages safely. - [Design a payment system](https://sysround.com/questions/design-payment-system): Ambiguous payment responses require retry policies tied to stable idempotency keys and reconciliation. - [Design a distributed job scheduler](https://sysround.com/questions/design-job-scheduler): Worker failures require durable retry scheduling without duplicating external side effects or overwhelming workers. - [Design a metrics monitoring system like Datadog](https://sysround.com/questions/design-metrics-monitoring-system): Ingestion retries and outage recovery must be bounded so accumulated samples do not overload recovering storage. - [Design an on-call escalation system like PagerDuty](https://sysround.com/questions/design-pagerduty): Uncertain provider delivery requires retries that respect escalation deadlines and distinguish delivery uncertainty from confirmed failure. - [Design a system to run commands across a fleet](https://sysround.com/questions/design-fleet-command-system): Fleet-wide reconnects and command redelivery need jitter, bounded attempts, and safe handling of uncertain execution outcomes. ## FAQ ### What is exponential backoff with jitter? Exponential backoff increases the delay cap after each failed attempt, usually doubling it until a maximum. Jitter randomizes the actual delay so clients do not retry at the same instant. Full jitter chooses a delay uniformly from zero to the current cap. ### How many retries should an API request use? There is no universal count: choose it from the request deadline, per-attempt timeout, failure type, and downstream capacity. Specify whether a limit counts retries or total attempts; three total attempts means the original call plus two retries. Stop when another useful attempt cannot fit within the remaining deadline. ### What is the difference between retries and a circuit breaker? Retries repeat an operation that may succeed after a temporary failure. A circuit breaker temporarily blocks calls when a dependency appears unhealthy, then allows limited probes to test recovery. They can work together, but neither makes duplicate side effects safe. ## Related concepts - [Idempotency and idempotency keys](https://sysround.com/concepts/idempotency) - [Circuit breakers](https://sysround.com/concepts/circuit-breaker) - [Backpressure](https://sysround.com/concepts/backpressure) - [Dead-letter queues](https://sysround.com/concepts/dead-letter-queue) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.