Systems field note
Interactive explanation · no sign-in
Reliability, in practice

Why retry jitter changes a traffic spike

When many clients fail together, they often retry together. Exponential backoff increases the wait, but a shared schedule can still produce synchronized waves. Randomized delays spread those waves out.

Try it, then read the assumptions.The little model below makes every client start at the same moment. That exaggerates the herd effect on purpose so the difference is easy to see.

The retry lab

Same clients, same retry budget, two scheduling rules.

Runs in this browser
20200
200 ms1,000 ms
26
Sample 1 · 100 ms time buckets

Fixed exponential backoff

Each client waits exactly the same amount before each retry.

0 s0 s
Busiest 100 ms window—

Full jitter

Each client draws a fresh delay from zero to the current backoff cap.

0 s0 s
Busiest 100 ms window—
What the bars show: The fixed schedule stacks retries into the same windows; independent draws tend to distribute them.
Read the model

Backoff solves one problem. Jitter solves another.

After a failed request, a client should not retry instantly in a tight loop. Exponential backoff makes later retries progressively less frequent. With a base delay of 400 ms, this model uses caps of 400, 800, 1,600, and 3,200 ms for four retries.

If every client uses those exact delays and their clocks start together, they all wake up together. The server gets a quieter interval followed by another concentrated burst. Full jitter chooses an independent random delay under each cap instead:

cap(n) = base × 2ⁿ
fixed delay(n) = cap(n)
full-jitter delay(n) = random value in [0, cap(n))

The chart counts retry attempts in 100 ms windows. It does not include the original failed request. Each client's next wait begins after its previous retry. The random sequence is seeded so a sample stays stable while you adjust the controls; the button starts a new sample.

What this simulation leaves out

  • Real clients rarely begin at exactly the same instant, and network latency already adds some variation.
  • A retry should have a maximum attempt count or time budget. Randomness is not a license to retry indefinitely.
  • Honor a server's Retry-After guidance where applicable. For overloaded services, a circuit breaker, queue, or admission control may matter more than the exact jitter formula.
  • Retries are only safe when the operation can be repeated safely or is protected by an idempotency mechanism.

The peak number is a property of this simple model, not a prediction for a production service. Use actual traffic traces and failure tests to set retry budgets.

A practical rule for clients

Choose a retry policy per operation. Set a cap and a deadline, add independent jitter, and make the request safe to repeat. Then measure whether retries help successful recovery or merely add load. The right policy is the one that lets the service recover without clients becoming a second outage.