Exponential Backoff

You call a friend. No answer. You call again immediately. No answer. You call again. And again. And again. Every 2 seconds, you call. Your friend's phone is buzzing non-stop, and if they were about to pick up, your constant calling is making it harder.

Now imagine 10,000 clients doing this to a struggling server. Each client retries every 100 milliseconds. The server was overloaded handling 10,000 requests per second, now it's getting 30,000 because everyone is retrying instantly. The server never recovers because the retries never let up.

Exponential backoff is the grown-up version of retrying. Instead of retrying immediately, you wait. And each subsequent retry waits exponentially longer. 100ms, 200ms, 400ms, 800ms, 1600ms. This gives the struggling service time to breathe, process its backlog, and recover.

Ethernet invented this in 1983 (IEEE 802.3). When two devices transmit simultaneously and collide, they each pick a random wait time from an exponentially growing window before retrying. Forty years later, the same algorithm runs in every AWS SDK, every gRPC client, and every Google Cloud library.

Exponential backoff uses this formula:

wait time = base * 2^attempt

With a maximum cap (usually 30-60 seconds), so you don't end up waiting 17 minutes on attempt 20.

Compare to fixed-interval retry (100ms between every attempt):

The trade-off is clear: exponential backoff takes longer to exhaust all retries, but it puts dramatically less pressure on the failing service. For transient failures, the first or second retry usually succeeds. The extra time for later retries is rarely needed.