Jitter (retries)
Jitter adds randomness to retry wait times so that many clients that receive errors simultaneously do not all retry at the same moment, which would recreate the overload that triggered the errors. Full jitter picks the wait time uniformly at random between 0 and the backoff ceiling. Decorrelated jitter (the AWS recommended approach) uses the previous sleep time to compute the next, producing a random walk through the backoff space.
Formula
AWS recommended formula: sleep = random_between(base, min(cap, random_between(base, prev_sleep × 3))).Why it matters in practice
Without jitter, a thundering herd that gets rate-limited retries in perfect synchrony — every client waits exactly 5 seconds then retries simultaneously, recreating the original spike. With jitter, retries are spread over the backoff window, reducing the instantaneous traffic to a fraction of the original burst. The effect compounds: exponential backoff with jitter turns a thundering herd into a gradual, manageable trickle of retries.
Common mistakes
- •Adding fixed jitter (e.g., ±500 ms) rather than randomising the entire wait — fixed jitter still allows correlated retries from clients that started at the same time.
- •Not seeding the random number generator uniquely per client — a shared seed produces correlated jitter, defeating the purpose.
- •Using jitter without exponential backoff — jitter alone does not reduce total retry volume; it only desynchronises the timing.