Software Engineering · Distributed Systems

Exponential Backoff

Reference entry · last updated August 24, 2026

Exponential backoff is a retry strategy in which a client that fails to complete an operation waits before retrying, with each successive wait growing exponentially — most commonly by doubling — up to a fixed maximum, instead of retrying immediately or after a fixed delay.[1] It is used throughout networking and distributed systems to reduce the load a wave of failing retries places on a resource that is already struggling.

The general shape

The delay before the n-th retry is typically computed as:

\( t_n = \min\bigl(t_{max},\ base \times 2^{n}\bigr) \)

where base is a starting delay (for example, 100 ms), n is the number of attempts already made, and t_max is a ceiling that stops the delay from growing without bound. The wait doubles with every failed attempt — roughly 1s, 2s, 4s, 8s, 16s — until it hits the cap, after which every further retry waits the same capped duration, or the client gives up once a retry limit is reached.

Origin: Ethernet's collision backoff

The technique originates in Ethernet's media access control, described by Robert Metcalfe and David Boggs in their 1976 paper introducing Ethernet.[2] When two stations on a shared cable transmit at the same time, their signals collide and both transmissions are lost. Instead of retransmitting immediately — which risks the same collision recurring — each station waits a random number of slot times, drawn from a window that doubles after every consecutive collision on that transmission: truncated binary exponential backoff. This keeps the network usable as contention rises, rather than letting it collapse into a continuous stream of collisions.

The synchronization problem

Exponential growth alone controls how much retry traffic exists, but not when that traffic arrives. If every client that fails at the same moment computes the same deterministic delay, all of them retry at the same instant — reproducing the original spike of concurrent requests, just one delay period later. This clustering is sometimes called a retry storm, or, when the synchronizing event is an outage recovering, the thundering herd problem: many clients wake at once and hit the recovering resource simultaneously, which can push it back into failure.

Jitter

The standard fix is jitter: adding randomness to the computed delay so that clients which failed at the same moment do not retry at the same moment. A widely-cited 2015 Amazon Web Services Architecture Blog post by Marc Brooker formalized three jittered variants and benchmarked them against plain exponential backoff:[1]

Full jitter — sleep = random(0, min(cap, base * 2 ** attempt)). The delay is a uniform random draw across the entire computed window, rather than a fixed value with randomness added on top.
Equal jitter — half of the computed delay is fixed and half is randomized, keeping a guaranteed minimum wait while still spreading the rest.
Decorrelated jitter — each delay is a random draw bounded by the previous delay rather than by the attempt count directly, decorrelating consecutive waits from one another.

Brooker's benchmarks found full jitter reduced the total work a contended system performed by more than half compared to backoff without jitter, at the cost of arriving slightly later on average — a tradeoff most systems accept.

Where it is used

Beyond Ethernet, exponential backoff with jitter is the default retry policy in most cloud SDKs, including AWS SDKs and Google Cloud client libraries,[3] in gRPC's retry configuration, and in HTTP clients handling 429 Too Many Requests or 503 Service Unavailable responses — often combined with a server-supplied Retry-After header that overrides the client's own computed delay when present.

What is not exponential backoff

A fixed retry interval — waiting the same duration between attempts regardless of how many have already failed — is not exponential backoff, even when it is loosely called "backoff." Linear backoff, where the delay grows by a constant increment each time (t_n = base × n rather than base × 2^n), is also a distinct strategy: it grows too slowly to relieve contention on a resource under heavy, sustained failure, which is the specific problem exponential growth is chosen to solve.

References

^ Marc Brooker, "Exponential Backoff and Jitter," AWS Architecture Blog, March 4, 2015 — https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/
^ R. M. Metcalfe and D. R. Boggs, "Ethernet: Distributed Packet Switching for Local Computer Networks," Communications of the ACM, vol. 19, no. 7, pp. 395–404, July 1976. DOI: 10.1145/360248.360253
^ "Retry strategy," Google Cloud Storage documentation — https://docs.cloud.google.com/storage/docs/retry-strategy

A freely-accessible full copy of the Metcalfe & Boggs 1976 paper was not located at time of writing; the ACM Digital Library entry is paywalled. Cited above by formal reference regardless.