29.5 How do retries with exponential backoff and jitter work?

At home: The switch trips. You wait a moment and try again. If it trips again, you wait longer before the next try, and after a couple of tries you stop and call the electrician.

In the system: Many failures are transient (a dropped packet, a brief overload, a restarting instance), so retrying often succeeds. If a call fails independently 1% of the time, two retries make success about 99.9999% (computed in the chapter's code). Rules (Chapter 24 covers the API side):

• Retry only transient errors (timeouts, 429, 503) and only safe operations (idempotent, or with an idempotency key).
• Exponential backoff: wait 100 ms, 200 ms, 400 ms ... up to a cap. This gives the dependency room to recover.
• Jitter: randomise each wait (for example, anywhere between 0 and the backoff), so thousands of clients don't retry at the same instant. The AWS Builders' Library describes this "full jitter" approach.
• Cap attempts and total time: a few attempts within the caller's deadline.
• Retry at one layer. If 3 layers each make 4 attempts, one user action can become 4 × 4 × 4 = 64 calls at the bottom.

The big caveat: the "99.9999%" assumes failures are independent. During a real outage, failures are correlated: every retry fails too, and retries just add load. That's the next section.

Memory code: "Wait, then try; wait longer, try again; then stop."

---