Why should retries use exponential backoff with jitter?
Backoff spaces out retries (1s, 2s, 4s...) so a struggling service gets room to recover. Jitter adds randomness so thousands of clients do not all retry at the same instant and cause a retry storm.
Explain it simply
A service has a brief outage. If every client retries immediately and repeatedly, the extra load keeps it down. Retries become the attack.
Exponential backoff: wait longer after each failure, for example 1 s, 2 s, 4 s, 8 s, up to a cap. This reduces pressure as the problem continues.
Jitter: add randomness to the wait. Without it, a thousand clients that failed together will retry together at 1 s, then at 3 s, then at 7 s, in synchronised waves. With jitter, each waits a random time within the window, so retries spread out.
Also:
- Set a maximum number of attempts and a total time budget.
- Retry only errors that may be temporary (timeouts, 503), not 400 or 404.
- Retry only idempotent operations, or use idempotency keys.
- Respect Retry-After headers.
- Consider a circuit breaker to stop calling a dependency that is clearly failing.
Example
Full jitter, base 1 s, cap 30 s:
attempt 1 fails -> wait random(0, 1 s)
attempt 2 fails -> wait random(0, 2 s)
attempt 3 fails -> wait random(0, 4 s)
attempt 4 fails -> wait random(0, 8 s)
After 5 attempts give up and report the error.What to say in the interview
"Exponential backoff gives the failing service breathing room, jitter prevents synchronised retry waves, and a cap plus attempt limit bounds the total effort. I only retry transient errors on idempotent calls and pair it with a circuit breaker."