Timeouts, retries, and the danger of making things worse

A natural response to a timeout is to retry. Often, that is reasonable. But the safety of retrying depends on the operation.

Suppose the original payment request took so long that your client timed out. You immediately submit the same request again.

If the provider processes both requests, the customer could be charged twice.

There is a second problem: the timeout might indicate that the provider is overloaded. Retrying aggressively adds more work to a service already struggling to keep up.

Retries can improve success rates during transient failures, but they can also amplify overload.

Three mechanisms help address this:

Timeouts

Bound how long a request can consume resources while waiting for a dependency. A timeout limits waiting; it does not cancel a remote side effect that has already started.

Idempotency

Make repeated requests with the same logical operation identifier safe. For example, a provider can recognise that two requests with the same idempotency key refer to one intended charge.

Backoff and jitter

Wait progressively longer between retries and introduce randomness into the delays, reducing the chance that many clients retry simultaneously.