REST API Fallback mechanism!

Handling API calls when the client or server is down requires planning for resilience, retries, and fallback mechanisms. Here’s how to approach it:

✅ 1. Clarify Who is Down


Scenario Strategy
🔴 Client is down Client retries later or uses message queue
🔴 Server is down Client implements retries, circuit breakers, fallback

 

Let’s focus on client making a call and the server is down.

🛠️ Strategies to Handle API Call When Server is Down

✅ A. Retry with Exponential Backoff

  • Automatically retry the failed request after waiting.
  • Increase wait time between attempts (e.g., 1s, 2s, 4s).

Example with Spring RestTemplate + RetryTemplate

RetryTemplate retryTemplate = new RetryTemplate();
retryTemplate.execute(context -> restTemplate.getForObject(url, String.class));

You can configure attempts, delay, backoff policy.

✅ B. Circuit Breaker Pattern

  • Prevent system overload by stopping calls after repeated failures.
  • Automatically retries when the service becomes healthy.

🔧 Tools:

  • Resilience4j (Recommended for Spring Boot)
  • Hystrix (deprecated)

@CircuitBreaker(name = "userApi", fallbackMethod = "fallbackUser")
public User getUser() {
    return restTemplate.getForObject("http://api/user", User.class);
}

public User fallbackUser(Exception e) {
    return new User("default", "offline");
}

✅ C. Queue the Request (Asynchronous Retry)

  • Send the request to a message queue (e.g., Kafka, RabbitMQ).
  • Retry processing when the server is back up.

  • Useful for non-blocking use cases like order processing, email sending, etc.

✅ D. Log and Alert

  • Log failure with request details.
  • Optionally alert DevOps team via Slack, Email, etc.

✅ E. Client Timeout and Graceful UI Response

  • Always set client-side timeouts.
  • Show proper fallback message to user: “Service temporarily unavailable, please try again later.”

🔍 Bonus: Detecting If Server is Down

  • Ping health check endpoint before making a heavy call.
  • Use Spring Boot Actuator on the server side: /actuator/health

🔒 Best Practices Summary

Practice Benefit
Retry with backoff Avoid hammering the server
Circuit breaker Fail fast, self-heal system
Fallback response Provide continuity to users
Message queue Ensure no data loss
Health checks Prevent unnecessary calls
Back to blog

Leave a comment