How exponential backoff works
After a temporary failure, the client waits before trying again. Each consecutive failure multiplies the delay, commonly by two, until it reaches a maximum cap. With a one-second base delay, the schedule could be:
delay = min(30 s, 1 s × 2^retry)
retry 0 → 1 s
retry 1 → 2 s
retry 2 → 4 s
retry 3 → 8 sThe cap prevents waits from growing without limit. Production clients usually add jitter by randomizing each delay. This stops many workers from retrying at the same instant and causing another traffic spike.
When to retry
Not every failed request should be retried.
- 429 Too Many Requests: Honor the
Retry-Afterheader when present. It contains either a delay in seconds or an HTTP date. Otherwise, use backoff and reduce your request rate. See 429 Too Many Requests. - 502, 503 and 504 responses: These are often temporary gateway or service failures. A website, CDN or proxy may send them. Retrying with backoff can be appropriate, especially for safe requests such as GET. See 503 Service Unavailable.
- Connection failures: A timeout or dropped connection may justify a retry, but only if repeating the operation is safe.
- 403 and 407 responses: Repeated attempts usually won’t fix denied website access or invalid proxy credentials. A 407 error requires correcting authentication.
Set both a maximum retry count and a total deadline. Don’t retry a non-idempotent POST unless the service supports an idempotency key.
Exponential vs linear and fixed backoff
Rate limiting is a rule enforced by a server. Backoff is how a client responds to failures or limits.
| Method | Wait pattern | Main trade-off |
|---|---|---|
| Fixed | Same delay each time | Simple but may align workers |
| Linear | Adds a constant amount | Grows slowly under heavy load |
| Exponential | Multiplies each delay | Reduces retries quickly but can become slow |
Using backoff with proxies
First identify who returned the error. If a website or CDN sends 429, slow down, honor Retry-After and lower your concurrency. Rotating the exit IP doesn’t remove limits tied to an account, cookie or broader network range.
For proxy connection failures, retrying another healthy endpoint may help, but keep a capped delay so your workers don’t overload the proxy gateway. Log the status, response headers, retry count and sender to distinguish target-site limits from proxy errors.
FAQ
Does exponential backoff always double the delay?
No. Exponential backoff uses a multiplier, and two is common but not required. The base delay, multiplier and maximum cap depend on the service and workload.
Should I use jitter with exponential backoff?
Yes, especially when many workers can fail together. Full jitter chooses a random delay between zero and the calculated exponential ceiling, reducing synchronized retries.
How many exponential backoff retries should I allow?
It depends on your deadline and the type of operation. Stop after a defined number of attempts or elapsed time, and follow any retry guidance provided by the API or website.