Glossary · 2 · Developer SDKs and APIs
Retry with exponential backoff
Also known as: Exponential backoff, Exponential backoff with jitter, Truncated exponential backoff
In distributed systems, retry with exponential backoff is a strategy for repeating a failed request after a transient error, in which the waiting time before each new attempt grows geometrically, usually up to a maximum delay and number of attempts, and is commonly randomized (jitter) so that many clients do not retry at the same moment.
- Developer SDKs
In one sentence
Retry with exponential backoff repeats failed requests after growing, randomized waits, up to a limit, so transient errors pass without overload.
Example
An SDK retries a timed-out upload after about 1, 2, 4 and 8 seconds, each wait randomized, and then reports the error to the application.
How it applies
- Building blocks: The strategy combines a retry (the repeated attempt) with backoff (the waiting rule). Typical parameters are the initial delay, the growth factor, the maximum delay, the maximum number of attempts or total time, and the kind of jitter.
- Which errors: Only transient failures should be retried: timeouts, dropped connections, 429 Too Many Requests and some 5xx responses. Invalid credentials, missing permissions or malformed requests fail again on every attempt. Google Cloud's documentation, for example, lists which errors its tools and client libraries retry.
- Idempotency as a precondition: A request is safe to repeat only if repeating it has the same effect as sending it once. HTTP defines PUT, DELETE and the safe methods as idempotent (RFC 9110, section 9.2.2); for other operations APIs often accept an idempotency key so that a retried request is not executed twice. See idempotency.
- Developer SDKs: Many client libraries retry by default. Their documentation should state the default policy, which operations and errors are retried, how to configure or disable retries, and how retries combine with timeouts set by the application.
- Layering: Retries can happen in the application, the SDK, a service mesh proxy and a gateway at the same time; stacked retries multiply the load on a failing service. Retry budgets and the circuit breaker pattern (in the software sense) limit this and keep a partial failure from spreading.
- Hardware and platform SDKs: Devices that lose connectivity, and extensions that call host APIs, use the same pattern; for a device fleet, jitter keeps thousands of devices from reconnecting in lockstep after an outage.
Exponential backoff vs. fixed-interval retry
A fixed-interval retry waits the same time between attempts; under load it keeps the pressure constant on a service that is trying to recover. Exponential backoff reduces the attempt rate over time, and jitter spreads attempts across clients. The AWS Builders' Library describes how adding jitter avoids synchronized retry waves.