Exponential Backoff and Jitter¶
Brooker, M. (2023). Exponential Backoff and Jitter. AWS Architecture Blog.
Cited by¶
7 citations across 7 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Thundering Herd
- The canonical fix is to spread the release window: replacing a synchronous release with one jittered uniformly over \([0, W]\) for \(W \gg \delta\) reduces the peak rate to \(n / W\), recovering the independence the queueing bound assumed.
This sourceEstablishes jitter (randomized backoff over a release window) as the canonical de-synchronization remedy for correlated retries, explicitly addressing the thundering-herd problem in which synchronized client retries spike load.
- The canonical fix is to spread the release window: replacing a synchronous release with one jittered uniformly over \([0, W]\) for \(W \gg \delta\) reduces the peak rate to \(n / W\), recovering the independence the queueing bound assumed.
Mechanisms¶
- Batch Job Staggering
- Its failure mode is the synchronized retry storm: if staggered jobs fail and all retry on the same fixed backoff, they re-synchronize into a fresh spike worse than the original — the classic thundering herd, where many clients wake and contend for one resource at once.
This sourceDemonstrates the contention created when many clients start together and try to update the same database row.
- Its failure mode is the synchronized retry storm: if staggered jobs fail and all retry on the same fixed backoff, they re-synchronize into a fresh spike worse than the original — the classic thundering herd, where many clients wake and contend for one resource at once.
- Exponential Backoff with Jitter
- Its signature failure mode is synchronized jitter — if every client seeds its randomness the same way, uses the same fixed window, or runs pure exponential backoff with no jitter
This sourceShows that exponential backoff without jitter leaves retry calls clustered and fails to resolve contention.
- Its signature failure mode is synchronized jitter — if every client seeds its randomness the same way, uses the same fixed window, or runs pure exponential backoff with no jitter
- Jittered Scheduling
- Worse, when the backend once stumbled and every client retried on the same fixed one-second timer, the retries re-synchronized into a retry storm that struck the recovering service exactly as it came back up.
This sourceShows that deterministic backoff can synchronize retries into recurring request spikes and that adding random jitter spreads those attempts over time.
- Worse, when the backend once stumbled and every client retried on the same fixed one-second timer, the retries re-synchronized into a retry storm that struck the recovering service exactly as it came back up.
- Pending State Polling
- Done well — with exponential backoff and jitter
This sourceShows that jittered exponential backoff spreads retry bursts and substantially reduces client work and server load under contention.
- Done well — with exponential backoff and jitter
- Randomized Polling Offset
- And adding an offset
This sourceShows that adding randomized jitter spreads otherwise clustered client retries.
- And adding an offset
- Try-Lock and Backoff
- Crucially, the backoff uses exponential backoff with jitter — each successive failure widens the wait and randomizes it — so the two services do not fall into a synchronized retry loop where they release, retry, and re-collide forever.
This sourceRecommends exponential backoff with jitter, widening successive retry intervals while randomizing them to reduce synchronized contention and repeated collisions.
- Crucially, the backoff uses exponential backoff with jitter — each successive failure widens the wait and randomizes it — so the two services do not fall into a synchronized retry loop where they release, retry, and re-collide forever.
Verification¶
Does it exist? Not checked yet. This entry carries no identifier to resolve. It was extracted from the citation as written in the article, normalized, and deduplicated against the rest of the registry.
Does it back the claim? Not recorded. Neither this nor any other of the 7 citations of this work carries a recorded support check.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:ba4d33733396 · see in the full table