Backoff: Why Shouldn’t We Retry Immediately After Failure?

Backoff: Why Shouldn't We Retry Immediately After Failure?

Backoff means not retrying a failed request immediately at the same pace. The system waits first, and often makes later waits progressively longer. It is neither giving up nor deciding that the fault has ended. It gives a dependent service time to recover while reducing the extra pressure created by retries themselves.

Suppose a ticketing service is briefly overloaded. If thousands of clients retry continuously and at once, they amplify the original congestion. Backoff spreads those requests across a longer period. Adding a little randomness can also stop every client from returning at exactly the same moment. The key question is not merely whether to retry, but when to retry and how many clients will do so together.

Backoff is related to a timeout but is not the same thing. A timeout ends the current wait; backoff schedules the next attempt. Rate limiting sets a speed boundary in advance, while a circuit breaker temporarily stops calls after repeated failures. Backoff specifically controls the rhythm at which action re-enters a system after failure.

https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/
https://cloud.google.com/storage/docs/retry-strategy


Discover more from Geoffrey Chen

Subscribe to get the latest posts sent to your email.