Circuit Breaker Pattern
Without circuit breakers, a failing downstream service can cascade failures throughout your system.
Quick answer: Circuit Breaker Pattern
Circuit Breaker Pattern is covered here as a practical system design concept. Without circuit breakers, a failing downstream service can cascade failures throughout your system. Use it to understand the Distributed Systems idea, where it appears in production systems, and how to discuss it clearly in interviews.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
The Core Idea
The circuit breaker pattern prevents a service from repeatedly calling a failing dependency. Like an electrical circuit breaker, it 'trips' open after detecting failures, rejecting requests immediately instead of wasting time and resources on calls that will fail.
Step-by-Step Walkthrough
Service A calls Service B through a circuit breaker. Initially, the circuit is Closed — all requests pass through. If 5 out of 10 requests to Service B fail, the circuit Opens. All subsequent requests to B fail immediately (no network call). After 30 seconds, the circuit moves to Half-Open — the next request passes through. If it succeeds, the circuit Closes. If it fails, it Opens again.
Why This Approach Wins
- Three states: Closed (normal — requests pass through), Open (tripped — requests fail immediately), Half-Open (testing — a few requests pass to check if the dependency recovered).
- Failure threshold: The circuit opens after N consecutive failures or a failure rate exceeding X% within a time window.
- Timeout: Open circuits automatically transition to Half-Open after a timeout (e.g., 30 seconds), allowing test requests.
- Fallback: When the circuit is open, return a fallback response (cached data, default value, error message) instead of an error.
- Per-dependency: Each downstream service should have its own circuit breaker. A failing payment service should not affect the search service.
In Production
Netflix Hystrix (now in maintenance) pioneered circuit breakers in microservices, protecting against cascading failures across hundreds of services.
Resilience4j is the modern Java circuit breaker library, used in Spring Boot applications.
Envoy proxy implements circuit breaking at the service mesh level, transparently protecting all services.
Tradeoffs and Limitations
- Protection vs Availability: Opening the circuit protects the system but makes the dependency completely unavailable (even for requests that might succeed).
- Threshold sensitivity: Too sensitive = false trips on transient errors. Too lenient = slow to protect against real failures.
- Fallback quality: A good fallback (cached data) maintains user experience. A bad fallback (empty response) confuses users.
Production Gotchas
- Not implementing circuit breakers at all — cascading failures bring down the entire system
- Using a single circuit breaker for all dependencies — one failing service trips the breaker for healthy ones
- Not providing a useful fallback — the circuit opens and users see cryptic errors
The Interview Angle
- What is the circuit breaker pattern?
- What are the three states of a circuit breaker?
- How does a circuit breaker prevent cascading failures?
- What fallback strategies can you use when the circuit is open?
Next Up
Original DosiBridge notes for Circuit Breaker Pattern
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Circuit Breaker Pattern is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Membership: For Circuit Breaker Pattern, decide the membership before choosing tools; otherwise the design looks clean but fails when circuit changes.
- Clock Drift: For Circuit Breaker Pattern, decide the clock drift before choosing tools; otherwise the design looks clean but fails when breaker changes.
- Retry Semantics: For Circuit Breaker Pattern, decide the retry semantics before choosing tools; otherwise the design looks clean but fails when circuit changes.
- Partition Behavior: For Circuit Breaker Pattern, decide the partition behavior before choosing tools; otherwise the design looks clean but fails when breaker changes.
- Reconciliation: For Circuit Breaker Pattern, decide the reconciliation before choosing tools; otherwise the design looks clean but fails when circuit changes.
Production review question
If a team adopts Circuit Breaker Pattern, what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track circuit-breaker health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Circuit Breaker Pattern, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.