What is the difference between linear and exponential backoff?

Linear backoff increases delay by a fixed amount each attempt (1s, 2s, 3s, 4s). Exponential backoff doubles the delay each time (1s, 2s, 4s, 8s, 16s). Exponential backoff is strongly preferred because it backs off more aggressively, giving the server more time to recover during sustained failures. Linear backoff sends too many retries too quickly when the server needs time to stabilize.

Why should I use full jitter instead of plain exponential backoff?

Without jitter, all clients that fail at the same time retry at the same intervals, recreating traffic spikes (thundering herd). Full jitter randomizes the delay across the entire range: random(0, baseDelay × 2^attempt). AWS research shows full jitter reduces total completion time by up to 40% and significantly lowers server load compared to exponential backoff without jitter. It provides the best distribution of retries over time.

What is a good maximum backoff cap?

The cap depends on context. For interactive user-facing requests: 5-10 seconds max with 3 retries (users won't wait longer). For background API sync: 30-60 seconds max with 5-10 retries. For batch processing or webhooks: up to 300-3600 seconds with many retries spread over hours. Without a cap, exponential backoff grows to absurd values (attempt 15 = 9 hours). Always set a cap and consider a total timeout budget as well.

Should I always retry on 500 Internal Server Error?

Retry cautiously. A 500 can be transient (temporary overload, deployment in progress) or persistent (code bug). Use exponential backoff with a low retry count (2-3 attempts) for idempotent requests (GET, PUT with idempotency key). For non-idempotent requests (POST without idempotency key), do NOT retry 500s — you risk duplicate side effects. If the 500 persists after retries, log it, alert, and return an error to the user.

How do I prevent retries from making an outage worse?

Use three complementary techniques: (1) Exponential backoff with full jitter spreads retries across time instead of all clients retrying simultaneously. (2) Retry budgets limit the percentage of total traffic that can be retries (typically 10%). (3) Circuit breakers stop all requests after repeated failures, giving the server time to recover. Together, these ensure your retry logic helps recovery rather than amplifying the problem.

Back-Off Strategies for API Clients