Retry

Overview

The retry pattern re-executes an operation that failed due to a transient fault, such as a dropped connection, a timeout, a 503, or throttling. Many failures in distributed systems are momentary, so a well-behaved retry turns them into successes invisible to users.

Retries must be safe and controlled: retry only idempotent operations (or use idempotency keys), only retryable errors, with exponential backoff and jitter, a small maximum number of attempts, an overall deadline, and ideally a retry budget. Uncontrolled retries are a leading cause of cascading failures and retry storms.

When to use it

• Network calls that occasionally fail transiently.
• Cloud APIs with throttling (429) responses.
• Database failovers and connection resets.
• Message processing with temporary downstream issues.

Where it shows up in interviews

Where it is used in real software

Key terms

Transient fault

Temporary failure likely to succeed if retried.

Backoff

Waiting longer between successive attempts.

Jitter

Randomness added to delays.

Retry budget

Cap on retries as a fraction of requests.

Deadline

Total time allowed including all attempts.

How it works, step by step

1. 1
   Fail the attempt quickly

   Per-attempt timeout.

2. 2
   Check retryability

   Error type and operation idempotency.

3. 3
   Back off with jitter

   Random delay up to an exponentially growing cap.

4. 4
   Stop at limits

   Max attempts, deadline, budget, or open circuit breaker.

5. 5
   Surface the failure

   Return a clear error or fallback, log with context.

Which failures to retry

HTTP and gRPC responses

Retrying non-retryable errors wastes resources and hides bugs.

Implementation

1import java.time.Duration;2import java.util.concurrent.Callable;3import java.util.concurrent.ThreadLocalRandom;4 5public final class Retry {6    public static <T> T withBackoff(Callable<T> op, int maxAttempts, Duration base, Duration cap) throws Exception {7        for (int attempt = 0; ; attempt++) {8            try {9                return op.call();10            } catch (Exception e) {11                if (!isRetryable(e) || attempt + 1 >= maxAttempts) throw e;12                long ceiling = Math.min(cap.toMillis(), base.toMillis() * (1L << attempt));13                long sleep = ThreadLocalRandom.current().nextLong(ceiling + 1); // full jitter14                Thread.sleep(sleep);15            }16        }17    }18 19    private static boolean isRetryable(Exception e) {20        return e instanceof java.net.SocketTimeoutException21            || e instanceof java.net.ConnectException22            || (e instanceof HttpStatusException h && (h.status() == 429 || h.status() >= 500));23    }24 25    public static final class HttpStatusException extends Exception {26        private final int status;27        public HttpStatusException(int status) { super("HTTP " + status); this.status = status; }28        public int status() { return status; }29    }30}

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Retrying at every layer.

  Fix: Retry at a single layer to avoid multiplicative storms.

• Retrying POSTs without idempotency keys.

  Fix: Duplicate orders or charges; add idempotency first.

• Fixed delays without jitter.

  Fix: Synchronized clients hit the service in waves.

Interview questions

Practice problems