Exponential backoff is a retry strategy where the wait between attempts grows each time a request fails. Try once and fail, wait one second. Fail again, wait two. Then four, then eight. The gaps stretch out fast, which keeps a struggling system from being buried under repeated requests.
Think of calling a friend whose line is busy. You don’t redial the same second over and over; you wait a bit, then a bit longer, giving them time to hang up. Exponential backoff is that instinct turned into a rule a computer follows exactly. It pairs naturally with retry logic, which decides whether to try again at all, and with throttling, which limits how fast you send requests in the first place.
Most real implementations add a small random delay called jitter. Without it, every client that failed at the same instant would retry at the same instant, recreating the very traffic jam backoff is meant to avoid. With jitter, the retries spread out and the load smooths over. Backoff also needs a ceiling, or two of them. One caps how long any single wait can grow, so you do not end up waiting an hour between tries. The other caps how many times you retry at all. After five attempts against a payment API that is still down, retrying a sixth time rarely helps. At that point the smart move is to stop and hand the failed item to a human or a holding queue, rather than loop quietly in the background. Picture a courier trying a locked door: knock, wait, knock again with longer gaps, but after a few tries leave a note rather than stand there all afternoon. Tuned well, the whole pattern turns a flaky connection from a source of dropped jobs into a minor delay nobody even notices.
At TopDevs we build exponential backoff into every integration that talks to an outside API, so a brief hiccup at the other end never turns into a cascade of failed jobs.
