Retry with Exponential Backoff

The Case for Retries

Networks are unreliable. Packets get dropped, connections time out, and services experience transient blips caused by garbage collection pauses, brief overloads, or rolling restarts. A simple retry — trying the same request again after a failure — can transparently recover from the majority of these transient errors without the user ever noticing a problem.

The challenge is doing retries safely: not overwhelming an already struggling service, not retrying non-recoverable errors, and not retrying non-idempotent operations that may have already succeeded.

Exponential Backoff

A naive retry immediately re-sends the request, which can make an overloaded service worse. Exponential backoff increases the wait time between retries geometrically: wait 1 s, then 2 s, then 4 s, then 8 s, up to a cap. This gives the service time to recover and reduces aggregate load during a degraded period.

async function retryWithBackoff<T>(
  fn: () => Promise<T>,
  options: {
    maxRetries?: number;
    baseDelayMs?: number;
    maxDelayMs?: number;
    jitter?: boolean;
    retryOn?: (err: unknown) => boolean;
  } = {}
): Promise<T> {
  const {
    maxRetries = 3,
    baseDelayMs = 500,
    maxDelayMs = 30_000,
    jitter = true,
    retryOn = () => true,
  } = options;

  let attempt = 0;
  while (true) {
    try {
      return await fn();
    } catch (err) {
      if (attempt >= maxRetries || !retryOn(err)) throw err;

      // Exponential backoff: 500ms, 1000ms, 2000ms, ...
      let delay = Math.min(baseDelayMs * 2 ** attempt, maxDelayMs);

      // Add jitter: ±30% of the delay
      if (jitter) delay *= 0.7 + Math.random() * 0.6;

      await sleep(delay);
      attempt++;
    }
  }
}

Adding Jitter

Without jitter, all clients that received an error at roughly the same time will retry at the same exponentially-backed-off moment — creating a thundering herd that re-hammers the recovering service in synchronized waves. Jitter adds random noise to the backoff delay so retries are spread across time. AWS recommends full jitter (random between 0 and cap) or decorrelated jitter (delay = random between base and prev_delay × 3).

When NOT to Retry

Idempotency Keys

To safely retry non-idempotent operations like payment charges, include an idempotency key — a unique ID generated by the client for each logical operation. The server stores the result keyed by this ID. On a retry, the server returns the stored result rather than re-executing the operation. Stripe, Braintree, and most payment APIs support idempotency keys via request headers like `Idempotency-Key: uuid-v4`.

Retry Budgets

At large scale, even 3 retries per original request can multiply load by 4× during an outage. Google's SRE book recommends retry budgets: a client maintains a token bucket where each retry consumes one token, and the budget limits the ratio of retries to original requests (e.g., retries cannot exceed 10% of traffic). This prevents retries from amplifying failures into cascading overload.