Glossary / Exponential backoff
Exponential backoff
Exponential backoff increases the delay between retry attempts, commonly multiplying a base delay by a factor such as two. It reduces pressure on a dependency that may be recovering from overload and gives transient faults time to clear. Backoff must be bounded and paired with attempt/deadline limits; unbounded delay or retries can leave user requests hanging indefinitely.
Delay schedule
A typical capped schedule is delay = min(maxDelay, baseDelay * 2^attempt). The exact initial attempt index and cap are policy decisions. Add jitter—random variation—to avoid synchronized clients retrying together. Consider server-provided retry guidance such as Retry-After, and ensure the overall request deadline includes both work and waits.
function backoff(attempt, base = 200, cap = 10_000) {
return Math.min(cap, base * 2 ** attempt);
}
This deterministic function is not sufficient for a fleet because every client with the same failure will retry simultaneously. Apply full or bounded jitter in production, and inject the random source/clock in tests. Avoid multiplying exponential schedules at nested service layers. Retry only safe operations and classify errors.
Interview questions
- Why increase delay exponentially? It reduces repeated load while a dependency recovers.
- Why cap the delay? To bound user wait and keep retry policy predictable.
- Why add jitter? To disperse synchronized retry bursts.
- What else bounds the policy? Attempt count and total deadline.