Retry With Exponential Backoff

Why retry at all

Networks drop packets, services restart, and brief overloads happen. Many failures are transient — the same request would succeed if tried again a moment later. Retrying turns a momentary blip into a non-event for your users.

But not every failure should be retried. A 400 Bad Request means your request is malformed; sending it again changes nothing. A 401 means your credentials are wrong. Retrying these wastes effort and hides real bugs. Retry the failures that are plausibly temporary: connection timeouts, 429 rate-limit responses, and 5xx server errors. Treat client errors in the 4xx range (other than 429) as final.

Why exponential

A fixed delay can make congestion worse: if a service is struggling and every client retries after one second, you hammer it with synchronised waves. Exponential backoff doubles the wait after each attempt — 1s, 2s, 4s, 8s — so pressure eases as the service recovers.

The growth gives a struggling system breathing room while still recovering quickly from a one-off glitch. Pair it with a sensible ceiling so the delay does not balloon to minutes. The combination of retry quickly at first, then back right off is what makes the pattern resilient rather than aggressive.

Add jitter

Exponential backoff alone still synchronises clients that failed at the same instant — they all wait 1s, then 2s, then 4s together, producing repeating spikes. Jitter adds a small random offset so attempts spread out across time.

base = 1.0
delay = min(cap, base * (2 ** attempt))
delay = delay * random.uniform(0.5, 1.0)

The randomness smooths the load into a steady trickle instead of sharp peaks. This matters most when many clients share a backend, which is the common case for a public API. Without jitter, your retries can become a self-inflicted denial of service.

Bound the loop

Retries must end. Set a maximum attempt count or an overall deadline so a permanently broken dependency does not trap a request forever. When the budget is exhausted, fail clearly and let the caller decide what to do.

• Max attempts — typically three to five for interactive calls.
• Overall deadline — stop once total elapsed time exceeds a threshold.
• Respect server hints — honour a Retry-After header when present.

Crucially, only retry operations that are safe to repeat. If a request might create or charge something twice, combine retries with idempotency so a duplicate has no extra effect.