Introduction
The Circuit Breaker Pattern is a defensive design pattern used to improve the resilience of distributed systems. It helps prevent the repeated execution of failed operations, which can lead to cascading failures, wasted resources, and degraded system performance. Commonly used in microservices and cloud-native Java applications, the pattern enables fast failure and graceful recovery.
🔌 What Is the Circuit Breaker Pattern?
The Circuit Breaker Pattern monitors the status of external service calls. If the failure rate exceeds a defined threshold, it 'opens the circuit' to block further calls temporarily. After a cooldown, it allows limited test requests ('half-open') to check service recovery.
UML-Style Structure
[Client]
|
|--> [Circuit Breaker Proxy] --> [Remote Service]
|
[Failure Detector / Timer]
Participants
- Client: Initiates the operation.
- Circuit Breaker: Intercepts and tracks failures.
- Service: Remote operation or API.
- Fallback Handler: Provides alternate logic on failure.
🌍 Real-World Use Cases
- API Gateways to detect failing microservices
- Payment gateways with temporary outages
- Database access layers in high-concurrency apps
- Third-party API wrappers with rate limits or instability
🧰 Implementation Strategies in Java
Using Resilience4j with Spring Boot
Maven Dependency
<dependency>
<groupId>io.github.resilience4j</groupId>
<artifactId>resilience4j-spring-boot2</artifactId>
<version>1.7.1</version>
</dependency>
Controller
@RestController
public class OrderController {
@Autowired
private OrderService orderService;
@GetMapping("/order/{id}")
@CircuitBreaker(name = "orderCB", fallbackMethod = "fallbackOrder")
public String getOrder(@PathVariable String id) {
return orderService.fetchOrder(id);
}
public String fallbackOrder(String id, Throwable t) {
return "Order service is currently unavailable.";
}
}
application.yml
resilience4j.circuitbreaker:
instances:
orderCB:
failureRateThreshold: 50
slidingWindowSize: 10
waitDurationInOpenState: 30s
✅ Pros and Cons
| Pros | Cons |
|---|---|
| Prevents cascading system failures | Adds complexity |
| Improves system availability | May obscure root cause |
| Helps in graceful degradation | Improper tuning can cause over-tripping |
⚠️ Anti-Patterns
- Missing fallback logic leads to client-side failure.
- Excessive retrying causes traffic spikes.
- Blindly trusting the fallback may return misleading responses.
- Too aggressive thresholds may degrade user experience.
🔁 Related Patterns Comparison
| Pattern | Use Case |
|---|---|
| Circuit Breaker | Stop repeated failures |
| Retry | Retry failed operation |
| Timeout | Abort calls taking too long |
| Bulkhead | Isolate failures between resources |
💻 Java Code Example – Custom Circuit Breaker
public class SimpleCircuitBreaker {
enum State { CLOSED, OPEN, HALF_OPEN }
private State state = State.CLOSED;
private int failureCount = 0;
private final int threshold = 3;
private long lastFailureTime = 0;
private final long openTimeout = 10000; // 10s
public String call(Supplier<String> service) {
long now = System.currentTimeMillis();
if (state == State.OPEN && (now - lastFailureTime < openTimeout)) {
return "Circuit is open.";
}
if (state == State.OPEN) state = State.HALF_OPEN;
try {
String result = service.get();
reset();
return result;
} catch (Exception e) {
recordFailure();
return "Service failed: " + e.getMessage();
}
}
private void reset() {
state = State.CLOSED;
failureCount = 0;
}
private void recordFailure() {
failureCount++;
lastFailureTime = System.currentTimeMillis();
if (failureCount >= threshold) {
state = State.OPEN;
}
}
}
🧹 Refactoring Legacy Code
Before
String data = restTemplate.getForObject("http://unstable-service/data", String.class);
After
@CircuitBreaker(name = "dataCB", fallbackMethod = "fallback")
public String getData() {
return restTemplate.getForObject("http://unstable-service/data", String.class);
}
public String fallback(Throwable t) {
return "Default data";
}
🌟 Best Practices
- Monitor metrics via Prometheus or Spring Actuator.
- Set sensible thresholds with real traffic in mind.
- Always include fallbacks.
- Avoid circuit breakers on idempotent endpoints (e.g., GETs).
- Combine with timeout and retry for stronger resilience.
🧠 Real-World Analogy
A house circuit breaker trips when electrical overload is detected, preventing damage. Once reset and stable, power resumes. Similarly, a software circuit breaker prevents repeated failures from overwhelming a system.
☕ Java Feature Relevance
- Lambdas: For service call abstraction (
Supplier). - Records: Structured fallback responses.
- CompletableFuture: For async circuit breaking (via resilience4j future support).
✅ Key Takeaways
- Circuit Breaker is a must-have for resilient microservices.
- It protects systems from cascading failures.
- Use Resilience4j for seamless integration in Spring Boot.
- Pair with fallback, timeout, and retry for best results.
❓ FAQ – Circuit Breaker Pattern in Java
1. What is a Circuit Breaker?
A design pattern that stops service calls after repeated failures.
2. When should I use it?
In remote service calls, DB operations, and any failure-prone areas.
3. Is Resilience4j better than Hystrix?
Yes. Hystrix is in maintenance mode; Resilience4j is the recommended choice.
4. What are the states?
CLOSED (normal), OPEN (block calls), HALF_OPEN (test recovery).
5. Can it work with async code?
Yes. Resilience4j supports async, RxJava, and CompletableFuture.
6. What if fallback also fails?
You can implement a fallback for your fallback, or log and return a default message.
7. Should I use it for all endpoints?
No. Use only for unstable or critical remote calls.
8. Can it monitor performance?
Yes, via Spring Boot Actuator and Micrometer.
9. How does it differ from Timeout?
Timeout aborts slow calls. Circuit breaker avoids failing ones altogether.
10. How do I test it?
Simulate failures or use test libraries like WireMock.