Chapter 12: Resilience Patterns with Resilience4j
In the previous chapter, we learned how to integrate our Insurance Policy Management System (IPMS) with external services using Feign Clients and WebClient.
Our system can now:
- Call External APIs
- Integrate with Payment Gateways
- Consume Partner Services
- Communicate with Notification Systems
However, there is a critical challenge.
What happens when an external service becomes slow?
What happens when a payment provider is unavailable?
What happens when a partner API continuously fails?
Without protection, a single failing dependency can impact the entire application.
In this chapter, we will learn how to build resilient APIs using Resilience4j and implement patterns such as Retry, Circuit Breaker, Bulkhead, Rate Limiting, Timeouts, and Fallbacks.
🎯 Learning Objectives
By the end of this chapter, you will be able to:
- Understand Resilience in Distributed Systems
- Implement Retry Pattern
- Implement Circuit Breaker Pattern
- Implement Bulkhead Pattern
- Implement Rate Limiting
- Configure Timeouts
- Implement Fallback Mechanisms
- Protect External Integrations
- Monitor Resilience Metrics
- Apply Enterprise Resilience Best Practices
Why Resilience Matters
Modern applications depend on multiple services.
Example:
Customer
↓
Policy Service
↓
Payment Service
↓
Notification Service
If any dependency fails:
Slow Response
Timeout
System Failure
Poor User Experience
Resilience patterns help applications survive failures gracefully.
Failure Scenarios in Insurance Systems
Examples:
Payment Gateway Unavailable
Customer Service Down
Email Service Slow
Partner API Timeout
Database Latency
Without resilience:
One Failure
↓
Cascading Failure
↓
System Outage
Resilience Architecture Overview
Resilience patterns isolate failures and protect critical business operations.
What is Resilience4j?
Resilience4j is a lightweight fault-tolerance library for Java applications.
Provides:
Retry
Circuit Breaker
Bulkhead
Rate Limiter
Time Limiter
Fallback
Designed for:
Spring Boot
Microservices
Cloud Native Applications
Adding Resilience4j
Maven Dependency
<dependency>
<groupId>
io.github.resilience4j
</groupId>
<artifactId>
resilience4j-spring-boot3
</artifactId>
</dependency>
Retry Pattern
Temporary failures often recover automatically.
Example:
Payment Gateway Timeout
↓
Retry Request
↓
Success
Retry Architecture
Application
↓
Call Service
↓
Failure
↓
Retry
↓
Retry
↓
Success
Retry Example
@Retry(
name = "paymentService"
)
public PaymentResponse process() {
}
Retry Configuration
resilience4j:
retry:
instances:
paymentService:
max-attempts: 3
Why Retry Carefully?
Too many retries may cause:
Increased Load
Duplicate Requests
Resource Exhaustion
Use retries only for transient failures.
Circuit Breaker Pattern
Suppose an external service is continuously failing.
Without protection:
Request
Request
Request
Request
Request
All fail.
System resources become exhausted.
Circuit Breaker Overview
Circuit Breaker stops calls to unhealthy services.
Circuit Breaker Architecture
Circuit breakers prevent repeated calls to failing services.
Circuit Breaker States
Three states exist.
Closed State
Normal Operation
Requests pass through.
Open State
Failures Exceeded Threshold
Requests are blocked.
Half Open State
Testing Recovery
Limited requests are allowed.
Circuit Breaker Example
@CircuitBreaker(
name = "paymentService"
)
public PaymentResponse process() {
}
Circuit Breaker Configuration
resilience4j:
circuitbreaker:
instances:
paymentService:
failure-rate-threshold: 50
Timeout Management
Slow services are often worse than failed services.
Example:
Request Sent
↓
Waiting...
↓
Waiting...
↓
Timeout
Time Limiter
Resilience4j provides:
Time Limiter
to restrict execution duration.
Time Limiter Example
@TimeLimiter(
name = "paymentService"
)
public CompletableFuture<
PaymentResponse> process() {
}
Bulkhead Pattern
Ships use bulkheads to prevent flooding.
Software uses the same concept.
Problem
Suppose:
Notification Service
becomes overloaded.
Without isolation:
Entire Application Slows Down
Bulkhead Architecture
Bulkheads isolate resources and prevent failure propagation.
Bulkhead Example
@Bulkhead(
name = "notificationService"
)
public void sendEmail() {
}
Rate Limiting
External APIs often impose limits.
Example:
100 Requests / Minute
Exceeding limits may result in:
429 Too Many Requests
Rate Limiter
Controls request volume.
Protects APIs
Prevents Abuse
Avoids Throttling
Rate Limiter Example
@RateLimiter(
name = "paymentService"
)
public PaymentResponse process() {
}
Fallback Mechanism
Fallbacks provide alternative responses.
Example:
Payment Service Down
↓
Return Friendly Message
instead of:
500 Internal Server Error
Fallback Example
@CircuitBreaker(
name = "paymentService",
fallbackMethod = "fallback"
)
public PaymentResponse process() {
}
Fallback Method
public PaymentResponse fallback(
Exception ex) {
return new PaymentResponse(
"SERVICE_UNAVAILABLE");
}
Fallback Processing Flow
Fallbacks improve user experience during failures.
Combining Patterns
Enterprise applications commonly combine:
Retry
+
Circuit Breaker
+
Timeout
+
Fallback
for maximum protection.
Insurance Payment Example
Policy Purchase
↓
Payment Gateway
↓
Timeout
↓
Retry
↓
Failure
↓
Circuit Breaker Opens
↓
Fallback Response
System remains operational.
Monitoring Resilience
Resilience patterns should be monitored.
Metrics include:
Retry Count
Failure Rate
Circuit Breaker State
Timeout Count
Rate Limit Violations
Monitoring Architecture
Observability is critical for resilience management.
Best Practices
✅ Use Circuit Breakers for external services
✅ Configure sensible retry counts
✅ Apply timeouts everywhere
✅ Use bulkheads for isolation
✅ Implement meaningful fallbacks
✅ Monitor resilience metrics
✅ Test failure scenarios regularly
Common Mistakes
❌ Unlimited retries
❌ Missing timeouts
❌ No fallback strategy
❌ Ignoring monitoring
❌ Sharing resources across services
❌ Using circuit breakers everywhere unnecessarily
Interview Questions
-
What is Resilience4j?
-
What is the Retry Pattern?
-
What is a Circuit Breaker?
-
Explain Circuit Breaker states.
-
What is a Bulkhead?
-
Why use Rate Limiting?
-
What is a Time Limiter?
-
What is a Fallback Method?
-
Why is resilience important in microservices?
-
How do you monitor resilience patterns?
Practice Exercises
-
Add Resilience4j to IPMS.
-
Implement Retry for Payment Service.
-
Configure Circuit Breaker.
-
Implement Time Limiter.
-
Configure Bulkhead for Notification Service.
-
Add Rate Limiting.
-
Create Fallback Methods.
-
Monitor Circuit Breaker Metrics.
Key Takeaways
- Distributed systems must expect failures.
- Resilience4j provides enterprise-grade fault tolerance.
- Retry handles transient failures.
- Circuit Breakers prevent cascading failures.
- Bulkheads isolate resources.
- Rate Limiting controls traffic.
- Timeouts prevent resource exhaustion.
- Fallbacks improve user experience.
- Monitoring is essential for resilience.
Chapter Summary
In this chapter, you learned:
- Resilience4j
- Retry Pattern
- Circuit Breaker
- Bulkhead
- Rate Limiting
- Time Limiter
- Fallback Mechanisms
- Resilience Monitoring
Our Insurance Policy Management System can now handle failures gracefully and remain available even when external services become slow or unavailable.
In the next chapter, we will focus on Microservices API Design, Service Decomposition, API Gateway, and Service Discovery.