Exponential backoff
A retry strategy where the wait between attempts grows multiplicatively, usually doubling each time. It gives an overloaded system room to recover instead of adding load.
Retrying immediately after a failure is the worst option available. If the upstream is struggling, an instant retry adds traffic at exactly the moment it can least absorb it.
Exponential backoff spaces attempts out. With a base delay of one second and a factor of two, the waits are 1s, 2s, 4s, 8s, 16s. Two limits keep it sane: a maximum number of attempts, and a cap on the individual delay so a job does not sit for an hour holding a connection.
Jitter is the part people leave out, and it is not optional at scale. Without a random offset, every client that failed during the same brief outage retries in lockstep: all at second 1, all at second 3, all at second 7. That is a retry storm, and it can turn a thirty second blip into a long outage. Full jitter is the simplest fix that works: instead of sleeping exactly base * 2^n, sleep a random duration between zero and base * 2^n.
A worked example. A workflow calls a partner API and receives HTTP 503. With base 500ms, factor 2, five attempts and full jitter, the waits might come out as 0.3s, 1.4s, 1.1s, 5.8s and 9.2s, roughly 18 seconds total. Most transient outages resolve inside that window, and a hundred clients running the same policy spread their load rather than arriving together.
Two rules that cost nothing. First, honour Retry-After when the server sends it, because the server knows when it will be ready and your formula is only a guess. Second, only apply backoff to transient failures. Backing off five times on an HTTP 400 just delays the moment somebody finds out the payload is malformed.
Backoff makes retries polite. It does not make them safe. Safety on write operations comes from idempotency.