The Retry pattern automatically re-attempts a failed service call after a short delay, used to recover from transient failures without manual intervention.
Key Points: • It should be used for transient failures like brief network blips or momentary service unavailability, not for permanent errors like bad requests or authentication failures. • Exponential backoff increases the delay between each retry attempt, reducing pressure on a struggling downstream service. • Jitter adds randomness to retry delays so that many clients retrying at once don't all hit the service at the same instant, avoiding a "thundering herd." • A maximum retry count is essential — retrying indefinitely can make an outage worse by amplifying load on an already-struggling service. • Retries should be combined with a Circuit Breaker so that once a service is clearly down, calls stop entirely instead of continuing to retry.
Example: If a call to an Inventory Service times out due to a brief network hiccup, retrying after 200ms, then 400ms, then 800ms (with jitter) often succeeds without the caller ever seeing an error, whereas retrying a 400 Bad Request would just waste resources.
Code Example:
@Retryable(
value = { TimeoutException.class },
maxAttempts = 3,
backoff = @Backoff(delay = 200, multiplier = 2)
)
public InventoryResponse checkStock(String sku) {
return inventoryClient.getStock(sku);
}Interview Tip: A concise interview answer is:
"I use the Retry pattern for transient, recoverable failures — like a brief network blip — with exponential backoff and jitter so retries don't overwhelm the failing service, and I always cap the number of attempts and pair it with a circuit breaker so retries stop once it's clear the service is genuinely down."