Reliability · advanced
Retries, exponential backoff, and jitter
A retry policy repeats eligible failed operations within a bounded budget; exponential backoff increases delay between attempts, and jitter randomizes delays so many clients do not retry in lockstep.
Why it matters
Retries can recover from transient failure, but uncontrolled retries amplify overload, duplicate side effects, and tail latency precisely when a dependency is least able to cope.
Mental model
How to reason about retries, exponential backoff, and jitter
A retry spends time and capacity for another chance. Admit only retryable failures, require a safe operation, increase spacing, randomize the crowd, and stop when the attempt or deadline budget is exhausted.
Analogy
If a busy office line fails, calling instantly and continuously joins everyone else in a redial storm; waiting progressively longer with a random offset spreads callers over time.
Examples
See the boundary, not just the happy path
Worked example · Bounded transient retry
attempt delays: random(0..100ms), random(0..200ms), random(0..400ms); stop at deadlineThe cap and deadline bound total cost, while full jitter reduces synchronized retry bursts.
Worked example · Respect server guidance
429 Too Many Requests with Retry-AfterThe response explicitly signals temporary rate limiting and may supply the earliest appropriate retry time.
Avoid · Retry a permanent client error
repeat the same malformed request after HTTP 400Nothing changes between attempts, so retries waste capacity and delay the actionable error.
Common mistakes
Misconceptions to remove early
Retrying at every service layer
Nested policies multiply attempts: three retries across three layers can create far more than three downstream calls. Choose a deliberate retry boundary.
Retrying non-idempotent work blindly
A timeout does not prove the server did nothing. Use idempotency, deduplication, or an operation-specific reconciliation strategy before repeating it.
Quick check
Can you predict the result?
1. What problem does jitter primarily address?
- • Many clients retrying at the same scheduled moments and causing synchronized load spikes
- • Incorrect JSON serialization
- • A mutex being unlocked twice
2. What four questions should a retry policy answer?
Keep building