Spring Boot Interview Question: Selective Retry on Network Errors

Network, retries, code samples, design and more

Scenario

You are building a Spring Boot Order Service that calls an external Payment Gateway to authorize payments.

Requirements:

• Retry transient network errors (like timeouts) and HTTP 5xx responses

• Fail fast on HTTP 4xx errors or validation failures

• Apply explicit timeouts to avoid hanging threads

• Do not retry non-transient network failures like SSLHandshakeException

During a traffic spike, some payment requests failed due to network timeouts, but no retries occurred because the retry configuration was misconfigured.

Why didn’t network timeouts trigger retries?

When a network timeout occurs in WebClient:

ReadTimeoutException (or SocketTimeoutException)
      wrapped in
WebClientRequestException (extends RuntimeException)

• Top-level exception thrown from the authorizePayment method is WebClientRequestException.

• The actual root cause (SocketTimeoutException) is wrapped inside.

@Retryable(include = SocketTimeoutException.class, maxAttempts = 3)

with this,

• Spring Retry only checks the top-level exception, not nested causes.

• Top-level exception here is WebClientRequestException, not SocketTimeoutException.

• Result: Spring Retry ignores the wrapped exception, so no retries happen for network timeouts

---

📢 Get actionable Java insights every week — from practical code tips to expert interview questions you can use today.

Join 3300+ subscribers and level up your Spring & backend skills with hand-crafted content — no fluff.

I want to offer an additional 40% discount ($ 18 per year) until January 31st.

Not convinced? Check out the details of the past work

---

How would you classify exceptions for:

• Network timeouts

• HTTP 5xx errors

• HTTP 4xx errors

• Non-retryable network errors (like SSLHandshakeException)

Network timeouts (transient network errors)

Examples:

• ReadTimeoutException

• SocketTimeoutException

• ConnectTimeoutException

Behavior / Retry:

• Usually transient — retrying may succeed on a subsequent attempt.

• In WebClient, these are wrapped inside WebClientRequestException.

• Should be retryable.

Spring Retry inclusion example:

include = WebClientRequestException.class

HTTP 5xx errors (server-side errors)

Examples:

• WebClientResponseException.InternalServerError (500)

• WebClientResponseException.BadGateway (502)

• WebClientResponseException.ServiceUnavailable (503)

Behavior / Retry:

• Indicates temporary server issues.

• Retrying usually makes sense after a delay.

• ✅ Should be retryable.

Spring Retry inclusion example:

include = WebClientResponseException.InternalServerError.class

HTTP 4xx errors (client-side errors)

Examples:

• WebClientResponseException.BadRequest (400)

• WebClientResponseException.Unauthorized (401)

• WebClientResponseException.Forbidden (403)

• WebClientResponseException.NotFound (404)

Behavior / Retry:

• Indicates client mistakes (wrong input, invalid authentication, missing resource).

• Retrying will not fix the problem.

• Should fail fast, not retried.

Spring Retry exclusion example:

exclude = WebClientResponseException.BadRequest.class

Non-retryable network errors (like SSLHandshakeException)

Examples:

• javax.net.ssl.SSLHandshakeException

• SSLPeerUnverifiedException

Behavior / Retry:

• These are configuration or certificate issues, not transient network failures.

• Retrying won’t help, might just overload downstream services.

• Should fail fast, excluded from retry.Problems

Spring Retry exclusion example:

exclude = SSLHandshakeException.class

How would you fix the retry logic ?

• Retry only wrapper exceptions for network failures

• Retry HTTP 5xx responses

• Fail fast on 4xx / validation errors

• Exclude non-retryable network errors

Explicit Timeout Configuration

We should configure two kind of timeouts:

• Connect timeout : Maximum time to establish a TCP connection to the server.

• Response timeout (read timeout): Maximum time to wait for the server to send a response after the connection is established.

Without timeouts, blocked threads can pile up during traffic spikes, leading to retry storms or thread exhaustion.

We can look at the latencies p99, p95, average from observability tool to identify the ideal value for the timeout.

What is a retry storm? Which techniques are useful to prevent them?

• Occurs when many requests fail simultaneously (e.g., network blip, downstream service slow)

• Each failing request retries immediately or with a fixed delay

• Result: thundering herd hitting the downstream service → worsens the problem, can cause cascading failures

Exponential backoff

• Instead of retrying at a fixed interval, increase the delay after each attempt:

@Retryable(
    maxAttempts = 5,
    backoff = @Backoff(delay = 500, multiplier = 2)
)

• Retry delays: 0.5s → 1s → 2s → 4s → 8s

• Reduces the chance that all retries hit the downstream service simultaneously.

Add jitter (randomized delay)

• Small random variation prevents multiple clients from retrying in lockstep:

@Retryable(
    maxAttempts = 5,
    backoff = @Backoff(delay = 500, multiplier = 2, random = 0.5)
)

• random = 0.5 adds up to 50% random variation to the delay

• Helps spread out retry requests over time

Limit max attempts

• Don’t retry forever — set a maxAttempts:

maxAttempts = 3

• Ensures failing requests fail fast after a reasonable number of retries

• Prevents infinite retry loops under prolonged outages

d) Use circuit breaker

• Circuit breakers stop sending requests to a failing downstream service temporarily

• Helps protect both your service and the downstream system:

// Example with Resilience4j
CircuitBreakerConfig config = CircuitBreakerConfig.custom()
    .failureRateThreshold(50) // open breaker if >50% failures
    .waitDurationInOpenState(Duration.ofSeconds(30))
    .build();

• Combine with retry: retry only when the circuit is closed, otherwise fail fast

e) Timeout + bulkhead

• Timeouts prevent threads from being blocked indefinitely

• Bulkheads limit concurrent calls per service or endpoint, preventing overload

// Resilience4j bulkhead example
SemaphoreBulkheadConfig config = SemaphoreBulkheadConfig.custom()
    .maxConcurrentCalls(50)
    .build();

• Ensures only a limited number of retries run at the same time

---

📚 Helpful Resources (7)

• 32+ Real-World Use Case-Based Java/Spring Boot Interview Questions

• Master DynamoDB with this premium course from Alex DeBrie

• Crack System Design Interview With Right Preparation

• Everything Bundle (Java + Spring Boot + SQL Interview + Certification)

• Get Your Hands Dirty on Clean Architecture (2nd edition)

---

Before you leave, lock in our special $18 annual subscription before January 31st! Don’t miss out—grab it here.

Happy Coding 🚀
Suraj