What Is the Circuit Breaker Pattern?
In a microservices architecture, Service A frequently calls Service B over the network. If Service B becomes slow or starts throwing errors, every call from Service A that waits on it ties up a thread or connection. Under load, this can exhaust Service A's own resources and cause it to fail too, even though the original problem was entirely inside Service B. The Circuit Breaker pattern wraps these outbound calls in a stateful proxy that tracks failures and, once a threshold is crossed, stops issuing new calls to the failing dependency entirely, failing fast instead of waiting.
Cricket analogy: When a fast bowler like Jasprit Bumrah keeps bowling no-balls due to an overstepping issue, the umpire eventually flags it and the captain pulls him from the attack rather than let every over compound the damage, just as a circuit breaker pulls a failing call out of rotation.
The Three States: Closed, Open, Half-Open
A circuit breaker operates as a state machine with three states. In the Closed state, calls pass through normally while the breaker counts failures within a rolling window; if the failure rate stays below a configured threshold (for example, 50% of the last 20 calls), it remains closed. Once failures cross the threshold, the breaker trips to the Open state, where it immediately rejects calls without attempting the network request, typically returning a fallback or an error. After a configured timeout (the 'reset timeout'), the breaker transitions to Half-Open, allowing a small number of trial calls through; if those succeed, it closes again, and if they fail, it reopens and restarts the timeout clock.
Cricket analogy: A bowler is 'closed' and trusted with the ball while his economy rate is reasonable, gets 'opened' (rested) after being smashed for three consecutive sixes, and is given a Half-Open trial over at the death only once the captain senses conditions have changed.
Implementing a Breaker in Code
Most teams don't hand-roll circuit breaker logic; they use a battle-tested library such as resilience4j for the JVM, Polly for .NET, or opossum for Node.js, and configure it with a failure-rate threshold, a sliding window size, and a wait duration before probing again. It's important to combine the breaker with a sensible fallback (a cached response, a default value, or a graceful error message) so that when the circuit is open, the caller degrades gracefully instead of just surfacing a raw exception to the end user.
Cricket analogy: A franchise doesn't invent its own fielding drills from scratch; it hires a specialist fielding coach (the library) and pairs strict catching-practice thresholds with a backup plan of extra boundary riders when a fielder is struggling, just as a breaker pairs thresholds with fallbacks.
// resilience4j circuit breaker example (Java)
CircuitBreakerConfig config = CircuitBreakerConfig.custom()
.failureRateThreshold(50) // trip if 50% of calls fail
.slidingWindowSize(20) // over the last 20 calls
.waitDurationInOpenState(Duration.ofSeconds(30))
.permittedNumberOfCallsInHalfOpenState(5)
.build();
CircuitBreaker breaker = CircuitBreaker.of("inventoryService", config);
Supplier<String> decorated = CircuitBreaker.decorateSupplier(breaker, () ->
inventoryClient.checkStock(productId));
String result = Try.ofSupplier(decorated)
.recover(throwable -> "UNKNOWN_STOCK_LEVEL") // fallback
.get();Don't set the failure-rate threshold and sliding window based on guesswork alone. A window that's too small (e.g., 5 calls) makes the breaker flap open and closed on normal noise; a window that's too large delays detection of a real outage. Tune these against real traffic patterns and load-test the transitions before relying on them in production.
Circuit breakers are often combined with bulkheads and timeouts: the timeout stops a single call from hanging forever, the bulkhead limits how many concurrent calls can be in flight to a dependency, and the breaker stops new calls altogether once failures are frequent. Together they form a defense-in-depth strategy against cascading failure.
- Circuit breakers prevent a failing downstream service from exhausting the caller's resources by failing fast instead of waiting on doomed calls.
- The pattern is a state machine with three states: Closed (normal), Open (rejecting calls), and Half-Open (testing recovery).
- Transitions are governed by a failure-rate threshold measured over a sliding window of recent calls.
- After tripping open, the breaker waits a configured reset timeout before allowing limited trial calls through.
- Production implementations should use established libraries (resilience4j, Polly, opossum) rather than custom state machines.
- Always pair a breaker with a meaningful fallback so users get graceful degradation, not raw exceptions.
- Breakers work best combined with timeouts and bulkheads as part of a layered resilience strategy.
Practice what you learned
1. What is the primary purpose of the Circuit Breaker pattern in microservices?
2. In the Open state, what does a circuit breaker do with new calls?
3. What happens during the Half-Open state?
4. Why should a circuit breaker be paired with a fallback?
5. Which combination of patterns is commonly used alongside circuit breakers for defense-in-depth resilience?
Was this page helpful?
You May Also Like
Retries and Timeouts
Two foundational resilience techniques for handling transient failures and slow responses when services call each other over the network.
Bulkhead Pattern
A resilience pattern that isolates resources per dependency or workload so that failure or saturation in one area can't sink the entire service.
Graceful Degradation
The design discipline of keeping a system partially functional and useful when some of its dependencies fail, instead of failing entirely.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics