Beyond try‑catch: 3 Elegant Fault‑Tolerance Patterns Every Senior Developer Needs

Environment : Spring Boot 3.5.0

1. Introduction

Exception handling alone does not guarantee stability; the recovery process after an exception is often ignored. Down‑stream timeouts without retries can lose orders, and long‑running requests can exhaust thread pools, causing application crashes. A robust recovery strategy is required for high‑availability services.

2. Practical Patterns

2.1 Retry – Not All Failures Are Final

Transient faults such as network glitches, database deadlocks, or rate‑limit responses can often be resolved by retrying, whereas permanent errors like validation failures cannot.

Incorrect Example 1 (no retry)

// ❌ No retry – a single transient failure becomes a permanent user‑side failure
public PaymentResponse chargeCard(PaymentRequest request) {
  // Call payment gateway
  // If timeout occurs, the method fails immediately with no remediation
  return paymentGateway.charge(request);
}

Incorrect Example 2 (naïve retry loop)

// ❌ Simple loop without back‑off or rate limiting
public PaymentResponse chargeCard(PaymentRequest request) {
  for (int i = 0; i < 3; i++) {
    try {
      return paymentGateway.charge(request);
    } catch (TimeoutException e) {
      // Immediate retry spikes the already overloaded downstream service
    }
  }
  throw new PaymentException("Retry failed");
}

Immediate retries from many concurrent users can create a “thundering herd” that overwhelms the downstream service.

Correct Example – Spring Retry with exponential back‑off and jitter

@Service
public class PaymentService {
  @Retryable(
    retryFor = {TimeoutException.class, ServiceUnavailableException.class},
    maxAttempts = 3,
    backoff = @Backoff(delay = 500, multiplier = 2, random = true)
  )
  public PaymentResponse chargeCard(PaymentRequest request) {
    return paymentGateway.charge(request);
  }

  @Recover
  public PaymentResponse handlePaymentFailure(Exception e, PaymentRequest request) {
    logger.error("Payment failed after all retries for orderId={}", request.getOrderId(), e);
    throw new PaymentException("Payment service unavailable. Please try again later.");
  }
}

Retries only transient exceptions, not validation or business failures.

Back‑off intervals: 500 ms → 1 s → 2 s (multiplier = 2).

Random jitter avoids synchronized retry bursts.

@Recover provides a clear fallback path when all attempts fail.

2.2 Circuit Breaker – Stop Calling a Failed Service

If a downstream service is completely down, retries only add latency and can block threads, eventually exhausting resources.

Incorrect Example – blocking call to a dead service

// ❌ Each request blocks for 30 s when the inventory service is down
public InventoryStatus checkInventory(Long productId) {
  // 100 concurrent users → 100 threads blocked for 30 s
  return inventoryClient.getStatus(productId);
}

A circuit breaker trips after a failure threshold, stops sending requests, and after a cool‑down period sends a test request to see if the service has recovered.

Correct Example – Resilience4j circuit breaker

@Service
public class InventoryService {
  @CircuitBreaker(name = "inventoryService", fallbackMethod = "fallbackInventory")
  public InventoryStatus checkInventory(Long productId) {
    return inventoryClient.getStatus(productId);
  }

  public InventoryStatus fallbackInventory(Long productId, Exception e) {
    logger.warn("Inventory service unavailable, returning fallback for productId={}", productId);
    return InventoryStatus.unknown("Inventory query temporarily unavailable");
  }
}

Configuration (application.yml):

resilience4j:
  circuitbreaker:
    instances:
      inventoryService:
        failure-rate-threshold: 50
        wait-duration-in-open-state: 10s
        sliding-window-size: 10

The fallback method returns a safe default value, preventing the whole request from crashing.

2.3 Idempotency – Safe Retries Without Duplicate Side Effects

When an operation partially succeeds (e.g., payment succeeds but order persistence fails), a blind retry can cause duplicate charges.

Incorrect Example – non‑idempotent order endpoint

// ❌ No idempotency – each retry triggers a new charge
@PostMapping("/orders")
public ResponseEntity<Order> placeOrder(@RequestBody OrderRequest request) {
  Payment payment = paymentService.charge(request.getPaymentInfo());
  Order order = orderService.create(request, payment);
  return ResponseEntity.status(HttpStatus.CREATED).body(order);
}

Correct Example – idempotency key header

// ✅ Idempotent order creation using Idempotency‑Key header
@PostMapping("/orders")
public ResponseEntity<Order> placeOrder(
    @RequestHeader("Idempotency-Key") String idempotencyKey,
    @RequestBody OrderRequest request) {

  Optional<Order> existing = idempotencyStore.find(idempotencyKey);
  if (existing.isPresent()) {
    logger.info("Duplicate request detected, returning cached result, key={}", idempotencyKey);
    return ResponseEntity.ok(existing.get());
  }

  Payment payment = paymentService.charge(request.getPaymentInfo());
  Order order = orderService.create(request, payment);
  idempotencyStore.save(idempotencyKey, order);
  return ResponseEntity.status(HttpStatus.CREATED).body(order);
}

@Service
public class IdempotencyStore {
  private final RedisTemplate<String, Order> redisTemplate;

  public Optional<Order> find(String key) {
    Order cached = redisTemplate.opsForValue().get("idempotency:" + key);
    return Optional.ofNullable(cached);
  }

  public void save(String key, Order order) {
    redisTemplate.opsForValue().set("idempotency:" + key, order, Duration.ofHours(24));
  }
}

Clients generate a unique Idempotency‑Key per request and resend it on retry; the server returns the previously stored result, preventing duplicate side effects.

2.4 Summary of the Three Patterns

Retry handles "small faults"—temporary failures that disappear on a subsequent attempt.

Circuit breaker handles "service outages"—persistent downstream failures.

Idempotency handles "downstream impact"—ensuring retries do not cause duplicate business effects.

Together they form a layered resilience shield for production‑grade Spring Boot applications.