A retry can help when a connection briefly drops, but it can make an outage worse when every client repeats work at once. A reliable retry policy is selective, bounded, and aware of whether the operation is safe to repeat.

Decide whether a retry is safe

  • Retry temporary connection failures and documented overload responses, not every client or validation error.
  • Retry a mutation only when the server supports an idempotency mechanism or the operation is otherwise safe to repeat.
  • Respect Retry-After when the server supplies it.
delay = min(maxDelay, baseDelay * 2^attempt) + randomJitter

Set a firm limit

Choose a maximum attempt count and an overall deadline. Stop when the caller cancels, report the final failure clearly, and record a metric for retry count rather than logging sensitive request data.

Test the policy with a deterministic clock and a sequence of simulated outcomes. Confirm a sustained outage does not create unbounded work or keep a user waiting indefinitely.