Exponential Backoff, Full Jitter or Decorrelated: Choosing a Retry Scheme

AWS has used FULL JITTER since Brooker's 2015 paper which made it the default. A reduced error count can be spread across time using a pseudo-random number generator to generate a minimum and cap for jitter.

Other formulae have been suggested as a compromise, most notably "Decorrelated Jitter" used in highly-deployed AWS services where contention is a failure mode frequently seen.

• Min (Request Count, Max Retries) vs a fixed Cap?

Retry Timing and Phase-Lock

Clients retry after an error: plain exponential backoff keeps errors bunched. This simply aligns retries, with the exponentially-expanded retries bunching up as tightly as the initial hits. Jitter spreads that out.

AWS's Reliability Pillar says to: use exponential backoff, introduce jitter, and limit the COUNT. As Marc Brooker’s 2015 blog explains, synchronized retries can overwhelm the service.

Many environments still rely on plain backoff. But this just leads clients to retry concurrently on the exponential curve again, which can "race through or overload." Jitter only shifts those phases.

AWS uses jitter in the wait function to break the "synchronization of client backoff." This is the same principle that the RELIABILITY PILLAR DOCUMENTATION says "when doing interaction retries, adding jitter to the wait times randomizes the retry sequence and helps avoid the thundering herd problem."

And that can be exactly what you are looking for when designing retry policies. Prevent mayhem from all your clients hammering the API when they retry.

Full Jitter as the Default

When asked about exponential backoff, AWS defaults to 2015 Brooker: random_element(0, min(cap, base 2 * attempt))

Decorrelated jitter came later, because the same retry pattern could still cluster around the exponential curve: "The reason we use Full Jitter in the AWS services is that we have found it to be a good balance of simplicity and performance. It does a good job of spreading out retries, but is easy to understand and implement."

Full jitter uses the minimum cap delay: 0 + random(min(cap, base * 2 ^ attempt)) AWS OSS DOCUMENTATION

This becomes the default because it is "simpler and it sees lower latencies."

Equal Jitter Versus Decorrelated Jitter

Other jitter alternatives try to meet a particular performance need. 50% Equal Jitter, for instance: cap/2 + random(0, cap/2) ELASTICDOG SUMMARY

Here, retries are divided in the retry cap timeout, equally between each retry.

Where there is contention or overload, the choice comes down to decorrelated or full jitter. For instance:

Decorrelated jitter min(cap, U(base, prev_delay * 3)) HERD README means retries from a single client do not bunch up.

But this version is used "when contention is the failure mode being protected against."

So it can be worth checking whether that exact case demands decorrelated in your given failure context.

When you need to implement, there's no "rule of thumb" in technical documentation – just the careful assessment of context, which should feed into your choice.

Retry Limits and Costs

When implementing in production, you need to put limits in place: retry count, retry delay, and total retry budget.

The AWS Reliability Pillar says that the client "can limit the number of times it retries an operation." This limit "depends on the specific implementation of the component, but a typical cap is NUMBER retries"

A survey from 2025 said most practitioners use an uncapped policy. But also that not limiting retries spreads load on the service, potentially creating a sign outage.

Handling spikes and slow-failures:

"instead of retries that happen based on an underlying exponential backoff algorithm, these retries use random delays. This makes it less likely that the retry will hit another spike in load, and instead land in the reduced load of the calm after the storm."

Here is the advantage of jitter. You can avoid the random spikes and bubbles of at least FACTOR load and failure.

A retry cap or a retry budget can ensure you do not keep retrying on a failing endpoint. Many surveyed developers use a capped retry policy but you need to pick a number.

For budget-driven or latency-driven services, a capped timeout is worth choosing and limiting.

What Not to Retry

When implementing a retry policy in your system, some errors must never be retried.

A source that explicitly lists which errors are non-retryable

It is important to filter these out before scheduling retry, especially at scale, and especially when retries can lengthen a loop.

We need to filter timeout, otherwise repeated 1s timeout requests can waste labor and SES. This applies to HTTP 500s, 502s, 503s, or other errors, without retrying them all.

When NON-RETRYABLE ERRORS occur on retrial, they can copy the retry problem across your whole network, overloading routers and disrupting the server itself.

With retry timing affecting real customers, and possibly introducing real financial costs, the choice of jitter and retry cap matters. It is worth choosing a retry strategy calculated on performance and impact, not defaulting to whatever the first generation did.

After all that, a decision can be made on the jitter strategy that works in your system. Tailor it on your error signs and retry patterns. And set a limit – or else you can send a herd right back to it, on the expo curve.