Retry storms: why exponential backoff isn’t enough without jitter
TL;DR
When an incident makes many requests fail at the same moment, clients retry at the same moment — even with exponential backoff, because their clocks stay in sync. Adding jitter (a random wait) spreads retries out so the server isn’t hit all at once.
The scenario in the video
| Backoff, no jitter | Backoff + full jitter | |
|---|---|---|
| Wait strategy | 0.8s, 1.6s… identical for every client | Random within [0, base·2ⁿ] |
| Load shape | All 12 requests hit at once, like a wall | Requests spread into a stream |
| Rejections (503) | 6 | 0 |
| Time to finish | 4.6s | 1.9s |
Same number of retries — only the timing differs.
How to put it to work
- Always combine exponential backoff + jitter + a retry cap + an overall timeout.
- Only retry transient errors (503, timeouts, dropped connections) — not 4xx caused by bad requests.
- Make retried operations idempotent (use idempotency keys for payments, order creation…).
- Pair with a circuit breaker to stop retrying entirely when the downstream service is down.