Retry jitter

Retry jitter introduces randomness into the wait before another call. It spreads attempts from multiple clients over time. This is particularly useful when many clients notice the same failure together: an identical pause can merely postpone the next load spike.

Three clients, different waits

In a fictional example, three clients may each choose a random wait within a 0–2 s window before their next attempt. They wait, for example, 0.4 s, 1.1 s and 1.7 s. These values illustrate the spread; they are not a recommended configuration. Attempts can still coincide with jitter.

The retry strategy still determines which errors justify another attempt, how many attempts are allowed and when the overall time limit is reached. The target system’s instructions on waiting times must be respected. With exponential backoff, the waiting range typically grows with further attempts up to a configured cap; jitter varies the actual pause according to the rule in use.

Randomness does not make repeating an operation safe. A lost response can conceal a write that already completed. Before another attempt, the integration therefore needs a safe repetition rule, such as idempotency or checking the outcome.

Sources

• AWS Builders’ Library: Timeouts, retries, and backoff with jitter

• AWS Architecture Blog: Exponential Backoff And Jitter