Retry repeats a failed operation when the failure may be temporary. It is a recovery choice for technical problems, especially remote calls: a timeout can reflect a brief network fault or short-lived unavailability rather than a permanent failure. Because remote calls are inherently unreliable, an immediate second attempt can keep an application running without changing its intended outcome. section 7.2.4
Treat retry as one part of a failure strategy, not the whole response. After a few reasonable unsuccessful attempts, stop sending calls to the unhealthy dependency: a circuit breaker can short-circuit later calls while it recovers. The application can then use a cached response or provide a clear, actionable error message instead of merely logging the failure. section 7.2.4
Choose retry by asking what kind of failure occurred and what recovery preserves useful behavior:
- Retry technical failures that may clear, such as an external-system timeout or temporary network problem. section 7.2.4
- Avoid treating logging as recovery when a practical attempt, fallback, or clear failure response is needed. section 7.2.4
- Limit attempts, then contain repeated failure with a circuit breaker and use an acceptable degraded outcome where available. section 7.2.4
Retries contribute to resilience: graceful recovery from unexpected dependency failures. They address failed operations; overload-control patterns such as rate limiting, backpressure, bulkheads, and time limits address a different problem—keeping the system stable under pressure. section 9.2
