Jitter

What is jitter?

Jitter is intentional randomness injected into timing to desynchronize independent actors. Its purpose is counterintuitive until you’ve seen the failure: many clients each behaving perfectly correctly, but in unison, become a coordinated stampede. Jitter scatters their timing so the aggregate load smooths out. It’s a one-line fix for a class of outages that look mysterious — periodic traffic spikes with no obvious cause — because the cause is synchronization itself.

The three places it matters most

Retries: pure exponential backoff synchronizes clients — everyone who failed at T retries at T+1, T+3, T+7, hammering a recovering service in waves exactly as it tries to come back. AWS’s analysis endorsed full jitter (sleep a random amount between 0 and the backoff cap) as the best-behaved variant; it’s the one to copy. Cache expiry: identical TTLs on popular keys mean they all expire simultaneously, and every request stampedes the database at once (the thundering herd / cache stampede) — jittered TTLs (TTL ± random) spread the repopulation. Cron and scheduled jobs: a fleet whose instances all run a task at 00:00:00 creates a synchronized load spike and can self-DDoS shared dependencies — jittering start times across a window fixes it.

Why it’s easy to forget

Jitter’s absence is invisible in testing — a few clients never synchronize noticeably; the failure only emerges at scale, in production, as an intermittent spike nobody can reproduce. That’s what makes “add jitter” one of the highest-leverage, lowest-effort reliability habits: a few characters of randomness preventing a category of hard-to-diagnose incidents. The mental trigger: any time many actors do the same timed thing, jitter it.

What people get wrong

• Exponential backoff without jitter — the textbook half-solution that still stampedes on recovery.
• Uniform cache TTLs on hot keys, converting an expiry into a database outage.
• Fleet-wide cron at round times — synchronized jobs hammering shared services on the minute.

Primary source: AWS Architecture Blog — Exponential Backoff and Jitter

Types of Jitter Strategies

There are several common approaches to adding jitter to a retry strategy, each with different tradeoffs: “full jitter” chooses a completely random delay between zero and the calculated maximum backoff value, providing the strongest spread of retry timing but potentially retrying sooner than the backoff schedule would otherwise suggest; “equal jitter” splits the delay into a fixed half and a random half, balancing some of backoff’s escalating delay guarantee against jitter’s spreading effect; and “decorrelated jitter” uses the previous delay to influence the next one, aiming to further reduce the chance of retries clustering together across many independent clients. The specific jitter strategy chosen matters less than simply including some form of jitter at all — the core benefit comes from avoiding synchronized retry bursts, which any of these variants accomplishes reasonably well compared to no jitter whatsoever.