Normal operation, requests pass through
Backend & Runtime / Knowledge library
Circuit Breaker Pattern
Stops calls to a failing dependency until a recovery probe is allowed
Why learn Circuit Breaker Pattern?
It prevents repeated slow failures from exhausting callers
The problem it solves
It contains cascading failure during downstream outages
Where it came from
Circuit Breaker Pattern is a software design pattern that stops calls to a failing dependency until a recovery probe is allowed. Its guarantees and tradeoffs depend on the concrete implementation and operating context.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define Circuit Breaker Pattern and distinguish it from a neighboring concept.
- Choose a realistic task where Circuit Breaker Pattern is appropriate.
- Identify a failure mode caused by misusing Circuit Breaker Pattern.
- Interpret a small design or result involving Circuit Breaker Pattern.
- Explain one tradeoff or limitation of Circuit Breaker Pattern.
Documentation and sources
- Patterns of Enterprise Application Architecture (martinfowler.com)
Connect the ideas
Explore next
Real World Example
Resilient Inventory Sync for Global Retail
Global e-commerce platforms requiring consistent inventory synchronization across distributed microservices.
The business problem
When a downstream inventory service experiences latency or outages, the calling order-processing service hangs while waiting for timeouts, leading to cascading resource exhaustion and thread starvation across the entire application stack.
How this topic solves it
The Circuit Breaker pattern acts as a state machine that monitors for failures in calls to the inventory service. When failure thresholds are exceeded, the breaker trips to an open state, immediately failing fast without attempting the remote call. This prevents the order-processing service from wasting resources on doomed requests, allowing the inventory service space to recover.
- Define a threshold for consecutive failures that triggers the transition from closed to open state.
- Implement a proxy or wrapper around the inventory service client to intercept all outgoing requests.
- Configure a timeout period for the open state, after which the breaker enters a half-open state to allow a limited number of test requests.
- Reset the breaker to the closed state if the test requests succeed, or return to open if they fail.
Shows how requests flow through the breaker states.
Failing fast, requests blocked
Testing recovery with limited traffic
- Closed State → Failure threshold reached → Open State
- Open State → Timeout period expired → Half-Open State
- Half-Open State → Test requests succeed → Closed State
- Half-Open State → Test requests fail → Open State
Expected business outcome
The system maintains overall stability during partial outages, ensuring that the order-processing service remains responsive even when the inventory service is unreachable.
Limitations and checks
A significant limitation is the risk of false positives where the breaker trips due to transient network blips rather than actual service failure. To check for this, developers must monitor the circuit state transitions and adjust the failure threshold and timeout duration based on observed error patterns rather than static defaults.