What are transient vs permanent failures and why does the distinction matter for retry?

Correctly classifying failures as transient or permanent is the foundation of any effective retry strategy. Retrying permanent failures wastes resources and delays the surfacing of bugs; failing to retry transient failures reduces system resilience unnecessarily.

Transient failures are temporary, self-healing conditions where the same operation, retried after a brief delay, has a realistic chance of succeeding:

• Network timeouts and connection resets
• Service temporarily unavailable (HTTP 503)
• Database deadlocks or lock timeouts
• Throttling responses (HTTP 429)
• Brief cloud resource contention

Permanent failures are errors where retrying the identical request will always produce the same result:

• Invalid request (HTTP 400 Bad Request)
• Unauthorized (HTTP 401) — credentials won't change between retries
• Resource not found (HTTP 404) — the resource won't appear on retry
• Data validation constraint violations
• Programming errors like NullPointerException

In Spring Retry, you encode this distinction through retryFor and noRetryFor:

@Retryable(
    retryFor = { SocketTimeoutException.class, HttpServerErrorException.class },
    noRetryFor = { HttpClientErrorException.class, IllegalArgumentException.class }
)

A well-designed retry policy only activates on exceptions that signal transient conditions, leaving permanent errors to surface immediately.