Do or Do Not. Then Retry.

Retrying is the most common failure remedy — and the easiest to get dangerously wrong.

When to Retry (and When Not To) #

The first filter is deterministic vs. IO: retrying can only help when the result could actually differ next time.

Retry IO / transient failures (timeouts, 5xx, network blips) — the world may have changed.
Never retry deterministic failures (parsing, validation, 4xx, auth) — same input, same code, same failure, forever. A retry loop here is a bug, not a safety net.
Only retry idempotent operations — or make them idempotent first.

Backoff Strategies #

Fixed delay — simple, but synchronizes clients.
Exponential backoff — base * 2^attempt; the default choice.
Jitter — randomize delays to prevent the thundering herd.
Cap the maximum delay and the total number of attempts.

The delay doubles each attempt, and jitter smears retries apart so a crowd of clients doesn't all reconnect at the same instant:

EXPONENTIAL BACKOFF (base = 100ms)

try 1  X            wait ~100ms
try 2  |X           wait ~200ms
try 3  |  X         wait ~400ms
try 4  |    X       wait ~800ms
try 5  |        X   give up (cap)
       |
       +-- delay = base * 2^attempt
           (doubles each retry)

WITHOUT JITTER      WITH JITTER
all retry in        spread out,
lockstep:           no stampede:

|XXXXX               | X  X X X X
|XXXXX               |X  X   X  X
 ^thundering herd     ^smeared out

Rules of thumb:
- cap the max delay AND attempts
- add jitter to avoid stampedes
- one deadline across ALL tries

Idempotency #

Idempotency keys so repeated requests apply once.
Safe-to-retry writes: upserts, conditional updates, dedup on the server.

Checkout is the standard example. If your server times out while creating a Stripe Checkout Session, you do not know whether Stripe created it. Retrying without an idempotency key may create a second session. Retrying with the same idempotency key lets the provider treat the repeated request as the same request.

Webhooks need the same discipline. Stripe may deliver the same event more than once. Your handler should record the event ID, check whether it has already been processed, and make fulfillment safe to run repeatedly.

Budgets and Limits #

Retry budgets — cap the fraction of traffic that is retries.
Deadlines/timeouts that span all attempts, not each one.
Interaction with circuit breakers — stop retrying a dead dependency.

Anti-Patterns #

Retrying inside every layer → exponential retry storms.
Retrying non-idempotent writes → duplicate side effects.
Infinite retries with no ceiling → resource exhaustion.

Front End vs. Back End Notes #

Front end: retry quietly a few times, then show a "Try again" affordance.
Back end: coordinate retries with backpressure so you don't amplify an outage.