What is the Retry with Backoff and Jitter pattern?
When a call fails for a temporary reason, try again after a delay that grows exponentially, with random jitter added so that many clients do not retry at the same moment. Stop after a maximum number of attempts or a total time limit.
What problem does the Retry with Backoff and Jitter pattern solve?
Many failures are momentary: a dropped connection, a deploy, a brief overload. A well-behaved retry hides them from users. A naive retry multiplies load on a struggling service and can turn a small problem into an outage, the classic retry storm.
How do you implement the Retry with Backoff and Jitter pattern?
- Retry only transient errors such as timeouts, connection resets and 503. Never retry 4xx errors.
- Retry only idempotent operations, or send an idempotency key so repeats are safe.
- Use exponential delays with a maximum, and randomise them with full jitter.
- Limit attempts and the total elapsed time, and consider a retry budget such as at most 10% extra requests.
- Retry at one layer only. Retries at every layer multiply.
When should you use it?
- Failures are often transient and the operation is safe to repeat.
When should you avoid it?
- The operation is not idempotent and you have no idempotency key.
- The dependency is clearly down. Let the circuit breaker stop the attempts.
What do you gain?
- Hides transient failures from users
- Simple to add
- Jitter spreads load over time
What does it cost?
- Adds latency to failing requests
- Can amplify load when misused
- Hard to reason about when stacked across layers
What are common mistakes with the Retry with Backoff and Jitter pattern?
- Fixed delays with no jitter, so every client retries in lockstep.
- Retrying at the gateway, the service and the client library, which multiplies attempts.
- Retrying a payment POST with no idempotency key.
Retry with Backoff and Jitter in practice
Chatterbox
After a brief database failover, every client retried on the same fixed interval. The synchronised waves of retries kept the database from recovering.
Clients and services switched to exponential backoff with full jitter and a cap on attempts. Reconnections spread out over time instead of arriving in waves.
Example decision record
- Context
- Brief network errors between services surface to users as failures.
- Decision
- Retry idempotent calls up to three times with exponential backoff and full jitter.
- Consequences
- Most transient errors are invisible to users.
- Non-idempotent calls are never retried unless they carry an idempotency key.