If retries aren’t randomly distributed over the retry window, a small perturbation (e.g., a network blip) can cause retry ripples to schedule at the same time, which can then amplify themselves
Using exponential backoff is great because if you keep retrying over and over without limits you’re eventually going to break something. Exponential backoff increases this retry period exponentially until you eventually give up. Jitter takes this one step further by adding a random difference between the retries so that if all requests fail at once, they are not all retried together after a short blip. Without jitter you may cause a ripple where all requests are retried at once causing further issues. for example a network being down for 1 second will cause all requests to pile up and be retried at once, then again and again, snowballing until a simple network error causes a wider server outage
https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/ https://sre.google/sre-book/addressing-cascading-failures/