The Simplest Fix
Imagine your service tries to save a file to a storage server, but the network blips for just a millisecond. The request fails. What should you do?
The simplest response to a momentary, or transient, failure is to just try the operation again. Often, the second attempt will succeed because the underlying cause — a brief network hiccup, a momentary CPU spike on the server — has already resolved itself. The Retry pattern is the most fundamental resiliency tool, and it is built into most HTTP client libraries and cloud SDKs.
When to Retry (and When Not To)
The critical discipline of the Retry pattern is knowing which failures are worth retrying. Retrying the wrong errors wastes resources and delays the user from getting a useful error message.
Retry these (transient faults):
- Network timeouts — the server may have been briefly overloaded.
- 503 Service Unavailable — the server is temporarily unable to handle the request.
- 429 Too Many Requests — you were rate-limited; wait and try again.
- Temporary database connection drops — the connection pool may have been momentarily exhausted.
Do NOT retry these (permanent faults):
- 404 Not Found — the resource does not exist; retrying will not create it.
- 401 Unauthorized — your credentials are wrong; retrying with the same credentials will always fail.
- 400 Bad Request — your request payload is malformed; the server will reject it every time.
- 409 Conflict — a business logic conflict exists; retrying may cause duplicate operations.
Retrying permanent faults is not just wasteful — it can be actively harmful. Retrying a 400 on a payment API could result in duplicate charges if the server processed the request but failed to send the response.
Interviewers often ask: "Is it always safe to retry a failed request?" The correct answer is no — and the key concept is idempotency. An operation is idempotent if calling it multiple times produces the same result as calling it once. GET and DELETE are naturally idempotent. POST (e.g., "create order") is often not. Before retrying, you must ensure the operation is idempotent, or use a client-generated idempotency key (a unique ID sent with the request so the server can detect and deduplicate retries).