Problem
Transient failures (network blip, GC pause, leader election) resolve quickly, but immediate retries amplify load and prevent recovery.
resilienceestablished · low operational burden
Retry with Exponential Backoff
Also known as: exponential-backoff, retry-pattern
Intent
Handle transient failures by retrying with increasing delays, avoiding thundering herd and giving downstream time to recover.
Forces
- •Transient failures are common in distributed systems
- •Immediate retries create thundering herd
- •Retries must not repeat indefinitely (resource exhaustion)
- •Different failure types need different retry policies
Solution
✓ When to Use
- •Idempotent operations (GET, PUT with idempotency key)
- •Transient failure scenarios: network, throttling, brief unavailability
- •Combined with circuit breaker (retry while closed, fail fast when open)
✗ When Not to Use
- •Non-idempotent operations without idempotency key
- •Permanent errors (4xx except 429, invalid input)
- •When latency budget is strict (user-facing latency SLO)
Pros
- +Simple, effective for transient failures
- +Jitter prevents thundering herd
- +Widely supported in SDKs and libraries
Cons
- −Increases tail latency for callers
- −Can mask systemic problems if overused
- −Retry storms possible if not combined with circuit breaker
Cost Profile
Infrastructure
None — client-side logic
Operational
Low — monitor retry rates
Cognitive
Low — standard pattern
Failure Modes
Retry storm: many clients retry simultaneously after outage
Retry amplification: retries increase load on already struggling service
Infinite retry loops on non-retryable errors
Real-World Examples
Alternatives
- circuit-breaker
- dead-letter-queue
- idempotency-key
Related Patterns
- circuit-breaker
- idempotency-key
- dead-letter-queue
Competency Domains
reliability opsdistribution communication