AWS's own SDKs default to a formula sometimes called 'decorrelated jitter': sleep = min(cap, random_between(base, previous_sleep * 3)). How does this differ mechanically from full jitter (random(0, min(cap, base * 2^attempt))), and why might it be preferred for long retry sequences?

## How full jitter draws each delay Full jitter, as commonly used elsewhere, computes each retry's delay independently: for attempt number n, it derives a deterministic exponential cap (`cap_n = min(maxDelay, base * factor^n)`) purely from the attempt index, and then draws the actual delay as `random(0, cap_n)`. Because this draw is independent each time — the formula has no memory of what the previous delay actually was, only of the attempt count — it's statistically possible, though not typical, for a client to draw a small delay on attempt 3, and then draw another small delay on attempt 4, purely by chance, even though the theoretical cap has grown between the two. Two consecutive short draws don't violate anything about full jitter's design, but they mean a specific client's actual observed delay sequence can look choppier or less smoothly increasing than the underlying exponential cap curve would suggest. ## What decorrelated jitter changes Decorrelated jitter, the formula AWS documents in its retry SDK guidance, changes the input to the randomization: rather than deriving each delay purely from the attempt index, it derives it from the previous actual delay the client used. The formula is typically written as `sleep = min(cap, random_between(base, previous_sleep * 3))` — the next delay is drawn uniformly between the base delay and three times whatever delay was actually used last time, then capped at the maximum. This has a self-reinforcing quality: - if the previous draw happened to be small, the next draw's upper bound (3x the previous) is also small, keeping the sequence in a lower range for a bit; - if the previous draw was large, the next draw's upper bound is correspondingly large, letting the sequence range higher. Over many attempts, this produces a delay sequence that trends upward with organic-looking variability, rather than being pinned to a purely deterministic, attempt-indexed ceiling with independent noise layered on top. Critically, because each draw depends on the actual realized previous value, two different clients that failed at the same instant and are both running decorrelated jitter are extremely unlikely to end up with correlated sequences even after several rounds, since their random draws diverge and then compound divergently — whereas with full jitter, two clients at the same attempt index are drawing from the identical `[0, cap_n]` range each round, so nothing structurally prevents a coincidental re-clustering at some later round even though each round is independently randomized. ## What the published comparison found In AWS's own published simulation results (from the 'Exponential Backoff and Jitter' AWS Architecture blog post), decorrelated jitter performed comparably to or slightly better than full jitter on aggregate metrics like total number of retries needed and completion time across a simulated population of clients recovering from a shared failure, while producing a visually smoother, more organically increasing delay curve per client with less of the choppiness full jitter can exhibit. This is why several AWS SDKs (and AWS's own recommended reference implementation) ship decorrelated jitter as the default retry policy rather than full jitter, even though full jitter remains extremely common and perfectly reasonable elsewhere since it only depends on the attempt index and is simpler to implement. ## The practical trade-off The practical trade-off is modest: - decorrelated jitter requires the client to carry state between attempts (the previous sleep value) rather than being able to compute delay n from the attempt index alone, a small implementation complexity cost; - it also makes the delay sequence slightly harder to reason about or bound tightly in advance, since the next delay's range depends on what was actually drawn last time rather than being knowable purely from 'this is attempt 4.' For most systems, the choice between full jitter and decorrelated jitter is a secondary tuning decision rather than a correctness-critical one — the primary, load-bearing decision is having some jitter at all versus none, since that's what prevents synchronized thundering-herd retries in the first place; the specific jitter formula chosen affects the smoothness and marginal efficiency of the spread, not whether the fundamental thundering-herd problem is solved. ## Where it shows up A concrete real-world reference is the AWS SDK for Java v2 and the AWS SDK for Go v2, both of which document `FULL_JITTER` and a decorrelated-style backoff strategy as selectable retry policies, with recent SDK major-version defaults favoring the jittered strategies over legacy fixed-delay retry to reflect the operational lessons AWS accumulated from large-scale client fleets. Engineers building custom retry logic for a high-fanout internal service — where many client instances are likely to fail together against a shared dependency — are the ones most likely to benefit from choosing decorrelated jitter deliberately over full jitter, while for lower-fanout, less-correlated failure scenarios the distinction rarely matters in practice.