Decision guide
Retry Strategies Compared
How should clients retry failed calls?
Side by side
| Criterion | No retry | Immediate retry | Exponential backoff + jitter | Retry with budget + breaker |
|---|---|---|---|---|
| Duplicate risk | None | If not idempotent | If not idempotent | If not idempotent |
| Load during outages | Lowest | High | Moderate | Bounded |
| Recovery from transient errors | None | Some | Good | Good |
| Synchronization risk | — | High | Low (jitter) | Low |
| Complexity | None | Trivial | Low | Medium |
When to choose each
No retry
Fail immediately and surface the error.
Choose when
- Non-idempotent operations without keys
- User-facing actions where the user can retry
Avoid when
- Transient network errors on idempotent reads
Immediate retry
Retry once right away.
Choose when
- Rare connection resets on idempotent calls
Avoid when
- Overload situations (adds load instantly)
Exponential backoff + jitter
Delays grow exponentially, randomized; capped attempts.
Choose when
- Default for idempotent/keyed calls
- Fleets of clients
Avoid when
- Tight latency budgets with no room to wait
Retry with budget + breaker
Backoff plus a cap on retry share of traffic and a breaker when dependency is unhealthy.
Choose when
- Service-to-service calls at scale
- Deep call graphs
Avoid when
- Simple scripts
Verdict
Use exponential backoff with full jitter, 2–3 attempts, honoring Retry-After — and only for idempotent or keyed requests. At scale, add retry budgets and circuit breakers, and retry at one layer only.
Learn more
- Resilience Patterns
- Idempotency & Retry-Safe Systems
- Performance & Scalability
- Call external APIs with retries and timeouts from FastAPI (FastAPI)
- Call external APIs with timeouts and retries in Node.js (Node.js)
- Call external APIs with timeouts and retries in PHP (PHP)