Several clients each retry a failed operation after the same fixed delay and keep colliding on every attempt, so almost none succeed. Explain what failure this is and why adding randomized jitter to the retry delay helps more than simply lengthening the delay.

## The failure: synchronised retry When several independent parties contend for one resource and all fail, each schedules a retry. If the retry policy is deterministic and identical across parties, their *relative* arrival offsets are preserved. Two clients that arrived 1 ms apart and both sleep 100 ms will arrive 1 ms apart again — and if the resource requires more than 1 ms of exclusive use, they collide again. The system is fully occupied, the retry counter climbs, and completed work approaches zero. Because everyone is runnable and mutating state, this is livelock, not deadlock. The pattern shows up at every scale: threads retrying an optimistic compare-and-swap, transactions retrying after a serialization conflict, HTTP clients retrying a 503, nodes retrying a leader election, radios retrying a shared medium, and pollers that all fire on a wall-clock boundary such as the top of the minute. ## Why a longer fixed delay does not fix it Think of two variables: **collision probability per round** and **rounds per second**. A longer fixed delay reduces rounds per second, so you burn less CPU and network — a real but secondary benefit. It does not touch collision probability, because the parties remain in phase. Formally, with N parties whose retry times are a common deterministic function of the attempt number, the arrival process stays a shifted copy of itself, so the same subset collides forever until some external noise (GC pause, scheduler hiccup, packet loss) accidentally breaks the tie. Relying on accidental noise is why these incidents are erratic and hard to reproduce. Worse, a long fixed delay *creates* a new hazard: it aligns clients into a periodic spike. Every delay period the resource sees N simultaneous arrivals and zero traffic in between, which is the worst possible arrival distribution for a queueing system. ## Why jitter works Jitter converts a deterministic schedule into a random one. If each party waits `U(0, W)` for window `W`, then the probability that two specific parties land within the resource's service time `s` of each other falls roughly as `s/W`, and the expected number of parties in the first slot is about `N·s/W`. Choosing `W` proportional to `N·s` makes the first arrival almost always unique: one party wins, completes, and leaves; the rest re-randomise and the population drains. That is the key property — **jitter makes the contending population shrink**, whereas fixed backoff keeps it constant. There are three common formulations, given a base delay `b`, attempt number `k` and cap `c`: - **No jitter**: `d = min(c, b·2^k)` — synchronised, bad. - **Equal jitter**: `d = h + random(0, h)` where `h = min(c, b·2^k)/2` — keeps a growing floor while spreading arrivals. - **Full jitter**: `d = random(0, min(c, b·2^k))` — the usual recommendation; it minimises both collisions and total work in simulation, at the cost of occasionally retrying very soon. Decorrelated jitter (`d = min(c, random(b, prev·3))`) is a variant that avoids the very short delays of full jitter while still de-synchronising. ## Choosing the parameters - **Base delay** should be at least the resource's service time; retrying faster than the operation can complete guarantees collisions. - **Growth factor** of 2 is conventional; the point of growth is to shrink offered load as the contending population turns out to be large. - **Cap** bounds worst-case latency; without it exponential growth drives tail latency into timeout territory. - **Attempt limit or retry budget**. Per-request attempt limits are not enough — a global budget (for example, retries may not exceed 10% of primary requests) is what prevents a partial outage from being amplified into a full one. Above the limit, fail fast or escalate to a fair, queued path that guarantees progress instead of racing. - **Retry only idempotent or safely-retryable work**, and only on error classes where a retry can plausibly succeed. ## Related but distinct: the thundering herd Jitter also addresses re-synchronisation events that have nothing to do with retries: a cache entry that expires at the same instant for all clients, a dependency that recovers and admits everyone at once, cron jobs on the same schedule, or reconnect storms after a network blip. Spreading expiry times and reconnect delays randomly is the same medicine. Note the difference in intent: backoff jitter de-synchronises *contenders*; herd jitter de-synchronises *arrivals*. Both are symmetry-breaking. ## Alternatives and complements Randomisation is not the only way to break symmetry. A deterministic tiebreaker also works and is often stronger: give each party a priority (id, timestamp, transaction age) and let the winner keep waiting while the loser aborts. Database concurrency control uses exactly this with wound-wait and wait-die. Alternatively, remove the contention: replace optimistic retry with a fair FIFO queue, batch conflicting work behind a single owner, or shard the resource so parties rarely meet. In practice a robust design layers them — jittered backoff for the common case, a bounded budget, and escalation to a queued path that guarantees an eventual turn.