Exponential backoff

What is exponential backoff?

Exponential backoff is a retry strategy where you double the wait after each failed attempt, so a struggling service gets progressively more room to recover instead of a wall of immediate retries. If the first retry waits one second, the next waits two, then four, then eight.

You reach for it on transient failures: a request times out, a database is briefly overloaded, or an API answers with a rate limit. Trying again straight away usually makes the overload worse. Backoff steps back a little further each time, which gives the other side space to catch up.

Walking through the delays

Pick a base delay and a multiplier of two. The wait for attempt n is base * 2^n, so with a one second base the sequence runs 1s, 2s, 4s, 8s, 16s, and would reach 32s next.

Left alone those numbers keep doubling, so you add a maximum delay, a cap. Once the computed wait passes the cap, every later retry waits the cap instead. Cap the example at 30 seconds and the sequence becomes 1s, 2s, 4s, 8s, 16s, 30s, 30s. This capped form is what Google Cloud calls truncated exponential backoff, and its client libraries default to a one second base, a multiplier of two, and a maximum somewhere between 30 and 60 seconds.

Why backoff alone is not enough

Here is the part most explanations skip. Backoff spreads retries out in time, but it does nothing to spread out the clients. If a thousand clients all fail in the same instant, they all wait one second, all retry together, all fail again, all wait two seconds, and retry together again. The doubling only creates quiet gaps between synchronised waves that still land in lockstep.

The fix is jitter: add randomness so each client picks a slightly different wait. With full jitter, described in the AWS Architecture Blog article on backoff and jitter, a client waits a random amount between zero and the computed backoff, so the retries smear across the whole window instead of stacking on one instant. Equal jitter is a middle ground: wait half the computed backoff for certain, then a random amount up to the other half, which keeps a guaranteed minimum gap. AWS found full jitter cleared the same work in fewer total calls, and it is the common default.

What to watch out for with exponential backoff

• Retry only safe operations. A retried charge or a duplicated email is worse than a clean error. Make the action idempotent before you retry it, otherwise backoff just multiplies the damage.

• Always set a cap and a retry limit. Without a maximum delay and a maximum number of attempts, a permanent failure quietly fills queues and hides the real problem instead of surfacing it.

• Do not retry permanent errors. Bad credentials or a validation error will not fix themselves by waiting. Backoff is for transient faults, and a retry policy should tell the two apart.

• Pair it with a circuit breaker. When a service is clearly down rather than merely busy, stop sending retries through it for a while. Grinding every request through its full backoff schedule only wastes time.