# Exponential Backoff

URL: https://softwaredictionary.org/terms/exponential-backoff
Category: Backend & APIs
Last updated: 2026-09-30

In short: Exponential backoff is a retry strategy that waits longer after each failed attempt, such as 1, 2, 4 and 8 seconds, so a struggling service can recover.

## What is exponential backoff?

When a network call fails, retrying immediately in a tight loop usually makes things worse: if the server is overloaded, a flood of instant retries only adds more load. Exponential backoff spaces retries out by multiplying the wait after each failure, typically doubling it. A client might wait 1 second, then 2, then 4, then 8, up to a maximum delay and a maximum number of attempts, before giving up and reporting the error.

Real implementations add jitter, a random variation in each delay. Without it, thousands of clients that failed at the same moment would also retry at the same moments, hitting the server in synchronized waves, a problem known as the thundering herd. A popular approach called full jitter picks a random delay between zero and the current exponential limit. Clients should also respect a `Retry-After` header when the server sends one, for example with a `429 Too Many Requests` or `503 Service Unavailable` response.

Exponential backoff is like calling a busy friend: if they don't answer, you try again in a minute, then in five minutes, then in an hour, rather than calling fifty times in a row. It is built into HTTP clients, cloud SDKs, message queue consumers, database drivers, and background job systems, and it appears in low-level protocols too: classic Ethernet used binary exponential backoff to recover when two devices transmitted at the same time.

Backoff is only half of a good retry policy. Retry only errors that are likely to be temporary, such as timeouts, dropped connections, `429`, and `5xx` responses, never errors like `400 Bad Request` or `401 Unauthorized`, which will fail the same way every time, and retry only idempotent operations, or use idempotency keys, so a retried payment doesn't charge a customer twice. Backoff is also different from a circuit breaker: backoff slows down retries of individual requests, while a circuit breaker stops sending requests to a failing service altogether for a while.

## Key takeaways

- Each retry waits longer than the last, usually doubling the delay.
- Random jitter keeps many clients from retrying in lockstep.
- Cap both the maximum delay and the number of attempts.
- Retry only temporary failures, and only operations that are safe to repeat.
- Honor a server's `Retry-After` header when it sends one.

## Example: Retrying a request with exponential backoff and full jitter

```javascript
async function fetchWithRetry(url, maxAttempts = 5) {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    const res = await fetch(url).catch(() => null); // network error -> null
    if (res && res.status !== 429 && res.status < 500) return res; // success or permanent error
    if (attempt === maxAttempts - 1) break;
    const limit = Math.min(30_000, 1000 * 2 ** attempt); // 1s, 2s, 4s, 8s... capped at 30s
    const delay = Math.random() * limit;                  // full jitter
    await new Promise((resolve) => setTimeout(resolve, delay));
  }
  throw new Error("Request failed after " + maxAttempts + " attempts");
}
```

## Frequently asked questions

**Why add jitter to exponential backoff?**

Without jitter, clients that failed together retry together, creating repeated traffic spikes that can keep a recovering server down. Randomizing each delay spreads the retries out evenly over time.

**How many times should I retry a failed request?**

For user-facing requests, 3 to 5 attempts with delays capped at a few tens of seconds is common. Background jobs can retry for much longer, and work that still fails is usually reported or moved to a dead-letter queue.

**What is the difference between exponential backoff and rate limiting?**

Rate limiting is enforced by a server to cap how many requests a client may send. Exponential backoff is how a well-behaved client reacts when requests are rejected or the server is failing.

---

Software Dictionary: https://softwaredictionary.org/ · https://softwaredictionary.org/llms.txt