How Circuit Breakers Work
IntermediateA circuit breaker protects a system from cascading failures. When a service keeps calling a dependency that is failing or slow, threads pile up waiting and the caller itself can go down — the failure spreads. A circuit breaker watches the failure rate and, once it crosses a threshold, "trips": it stops calling the failing dependency and fails fast (often returning a fallback) instead. After a cool-down it cautiously tests whether the dependency has recovered.
Think of it as an electrical fuse
A fuse in your house protects the wiring: if a device draws dangerous current, the fuse trips and cuts the circuit, preventing a fire that would spread through the whole house. A software circuit breaker does the same for calls to a failing service — it trips to stop the flood of failing requests from overloading and taking down the caller. Once things look safe, you flip the breaker back on and test carefully.
Step by Step
Key Concepts
Closed / Open / Half-Open
The three states. Closed = calls flow and are monitored. Open = calls fail fast without hitting the dependency. Half-open = a few trial calls test whether it has recovered before fully closing.
Cascading Failure
When one failing service causes its callers to exhaust threads waiting on it, so they fail too, and the failure spreads upstream. Circuit breakers exist to contain this.
Fallback
The alternative response returned while the breaker is open — a cached value, default, or degraded feature — so the application stays usable instead of erroring out.
Bulkhead
A complementary pattern that isolates resources (e.g., a separate thread pool per dependency) so one saturated dependency cannot consume all threads and sink the whole service.
Key Facts
- A circuit breaker without a sensible timeout is far less effective — slow calls, not just errors, are what exhaust threads and cause cascades.
- Failing fast is a feature: returning an instant fallback beats making users wait on a doomed call that will time out anyway.
- Libraries like Resilience4j (and formerly Hystrix) provide circuit breakers, retries, rate limiters, and bulkheads as composable resilience building blocks.
Real-World Applications
Protecting a checkout from a flaky dependency
If a recommendations service goes down, a circuit breaker around it trips and returns an empty list, so checkout still works — the non-critical feature degrades instead of taking the whole page down.
Preventing thread-pool exhaustion
When a downstream API slows to a crawl, the breaker opens so calls fail instantly rather than tying up every worker thread, keeping the rest of the service responsive.
Frequently Asked Questions
What are the three states of a circuit breaker?
Closed, open, and half-open. In the closed state calls pass through normally while success and failure rates are tracked. When failures exceed a threshold the breaker opens and rejects calls immediately (failing fast). After a cool-down it becomes half-open, allowing a few trial calls; if they succeed it closes, and if they fail it re-opens.
What problem does the circuit breaker pattern solve?
It prevents cascading failures. When a dependency is slow or down, callers waiting on timeouts exhaust their threads and connections, become unresponsive, and cause their own callers to fail — the failure spreads. A circuit breaker trips to stop calling the failing dependency, failing fast so the caller stays healthy and the failure is contained.
What is a fallback in the circuit breaker pattern?
A fallback is the alternative response returned while the breaker is open, instead of an error. It might be a cached value, a sensible default, or a degraded version of the feature. Fallbacks let the application stay usable during a dependency outage, so a non-critical failure does not break the whole user experience.
How is a circuit breaker different from a retry?
A retry re-attempts a failed call, hoping it succeeds — useful for transient glitches, but harmful if the dependency is truly down (retries add load). A circuit breaker detects sustained failure and stops calling altogether, failing fast. They are complementary: retry transient errors, but let a circuit breaker cut off a persistently failing dependency.