What is exponential backoff?
Exponential backoff lengthens the interval between retries, so each attempt waits longer than the one before it. A struggling dependency is given room to recover instead of meeting a constant stream of attempts. A random element is added to each interval so that many clients do not retry in unison.
Also called: Backoff and jitter
Why a retry policy can be the cause of an outage
Most retry loops are written in the ten minutes after an intermittent failure, and they use a fixed interval with a generous attempt count. Under a partial outage every client then retries at the same cadence, and the retries themselves become the load that prevents recovery. Exponential backoff with jitter removes both properties: the interval grows and the clients disperse. It is a small amount of code that decides whether a degraded system recovers or collapses.
- A fixed retry interval synchronises clients into a load the system cannot absorb.
- Growing intervals give a degraded dependency time to recover.
- Jitter disperses attempts so recovery is not interrupted by a synchronised herd.
- A finite attempt count is what makes failure visible instead of perpetual.
How exponential backoff works
- A base interval and a growth factor are chosen from the dependency's recovery profile.
- Each successive attempt waits the previous interval multiplied by that factor.
- A random offset is applied so concurrent clients separate from each other.
- An upper bound caps the interval so a task does not wait indefinitely.
- Attempts stop at a defined limit and the work moves to a dead letter destination.
- Errors are classified first, since a permanent rejection should never be retried.
How exponential backoff is evaluated
A retry policy is assessed against the behaviour of the dependency it protects. Measure the following during a degradation rather than in steady state:
- request volume reaching the dependency during an incident
- distribution of retry attempts per task
- proportion of tasks succeeding on a retry rather than failing
- time to recovery with and without the policy applied
- permanent errors retried in error
Limitations, risks and common failure modes
- Retries are applied to errors that can never succeed, such as a validation rejection.
- An unbounded interval leaves a task waiting past its business deadline.
- Backoff is implemented without jitter, so the clients remain synchronised.
- Each layer of the stack retries independently, multiplying the load downstream.