Jitter

Jitter, in the context of retries, is deliberate randomness added to the waiting interval so that clients which failed at the same moment do not retry at the same moment.

It exists because of a specific failure mode. When a shared dependency fails, every caller notices at roughly the same time and starts the same retry schedule. Exponential backoff alone keeps them synchronized: they all wait one second, then two, then four, and each of those moments delivers a spike of traffic to a service that is trying to recover. Marc Brooker’s analysis for AWS shows the effect and the fix, which is to randomize the interval rather than compute it deterministically.

Several forms are in common use. Full jitter picks a random wait between zero and the current backoff ceiling. Equal jitter takes half the computed interval plus a random half. Decorrelated jitter derives each wait from the previous one. They differ in how aggressively they spread load; in the contention experiment AWS published, each of them completed the same work with fewer calls than backoff without jitter, which is the comparison the recommendation rests on.

The same reasoning applies beyond retries, and this is the part teams usually miss. Scheduled jobs that all start on the hour, caches that expire together, and health checks aligned to a round interval produce synchronized load for the same reason. Spreading start times is the same remedy under a different name.

One caution on the word: in networking, jitter means variation in packet delay, which is a measurement rather than a technique. The two senses are unrelated, and context usually disambiguates them.

How it combines with exponential backoff and where retries remain unsafe is worked through in Partial Failure, Timeouts, and Retries.

References

• Marc Brooker, Exponential Backoff And Jitter — AWS Architecture Blog