cloudpatterns.appClassroomKatasWhiteboardBlog
Z3 · Resilience & Reliability

Retries with backoff and jitter

Retries with backoff and jitter

Bronze

Retrying a failed call turns a brief glitch into a success — but every retry is extra load on a dependency that may already be struggling, so retry only what is safe to repeat, a few times, waiting longer each time with some randomness.

Use when
Brief, transient failures — a dropped connection, a busy dependency · Operations that are safe to repeat
Avoid when
Failures that won't go away on their own — bad input, missing permission · Retrying an overloaded dependency right away, without limit — it adds to the load
Trade-offs
Each retry raises the chance of success and the load on the dependency · Backoff waits cost latency; no waiting costs synchronized retry waves
Requires
Timeouts
3 objectives · 13 misconceptions
  • choose Choose which failures to retry — transient ones, on operations that are safe to repeat — and which to fail fast.
  • explain Explain why waiting longer after each attempt, with random jitter, keeps retries from arriving in synchronized waves.
  • predict Predict how retries at several layers multiply the load on a failing dependency.
  • Not true: Retrying a failed call can only make things better.
  • Not true: The best time to retry is right away.
  • Not true: Every layer should retry on its own, to be safe.
  • Not true: Any failed operation can be retried, including ones that change data.
  • Not true: More retry attempts mean higher reliability.
  • Not true: Retries belong closest to the failing service.
  • Not true: A limit on attempts per call is enough to keep the extra load from retries small.
  • Not true: Backing off reduces how many retries arrive in total.
  • Not true: Backing off is enough on its own to keep clients from retrying at the same moment.
  • Not true: A retry adds no real load — it just takes the failed call's place.
  • Not true: Retries multiply every call by its number of attempts, even when few calls fail.
  • Not true: A rush of retries clears up on its own once the failing service is back.
  • Not true: Retries at different layers add up at most — they don't multiply.

Neighborhood

builds onTimeouts
Retries with backoff and jitter
On linesResilience Line

Progress is saved on this device