Retries, backoff and jitter
When a retry helps and when it starts a retry storm: amplification across layers, capped exponential backoff, full jitter and retry budgets.
30 min7 steps
By the end you can
- Decide which failures are worth retrying and which are not
- Compute how retries at several layers multiply load on a failing dependency
- Compute capped exponential backoff schedules and explain why jitter matters
- Bound total retry load with a retry budget and choose where in the stack to retry
Retries fix transient failures, and only those
Retry
- Dropped packet
- Election in progress
- 503 / 429 after waiting
Never
- 400 Bad Request
- 403 Forbidden
- Fails identically
Careful
- Non-idempotent op after timeout
- Might run twice
Retries multiply across layers
Loading question…
Exponential backoff with a cap
- Retry 1100 ms
- Retry 4800 ms
- Retry 76,400 ms
- Retry 10 (uncapped)51,200 ms
Log scale: each gridline step is 10×.
Loading question…
Jitter spreads the herd
Plain backoff
- All retry at 100, 200, 400 ms
- Synchronised spikes
Full jitter
- Sleep random(0, capped exp)
- Even spread, less total work
- Brooker, AWS 2015
Loading question…
Retry budgets bound the worst case
Healthy
never reached
transients still retried
Dependency failing
+10% load max
instead of multiplying
Rule
retries / first attempts
commonly about 10%
Loading question…
Anatomy of a retry storm
0 s
Failover slows the database
5 s
Timeouts, every layer retries
30 s
Database healthy again
40 s
Retry load keeps it slow
Later
Outage persists, cause gone
Check your mastery, then start a storm
3 retries, no backoff
storm
Backoff + full jitter, fewer retries
less load
Score 80% or more. In the sandbox, build client, service, circuit breaker, downstream returning 503. Set three retries with no backoff, run, then add backoff with full jitter.
Mastery check
6 questions on fresh variants. One attempt each, no time limit. Score 80% or more to master the lesson.
Answer this step to continue.