What is a circuit breaker?
A third party's outage becomes your outage the moment your app keeps calling it anyway.
Circuit breaker
A circuit breaker is a code pattern that stops calling a dependency once it has failed too many times. It waits, checks whether the dependency has recovered, then lets traffic flow again.
The name comes from an electrical circuit breaker, which trips and cuts the current rather than letting a fault keep drawing power. A software circuit breaker does the same job around a call to another service: a payment processor, a third-party API, a database.
Without one, every request that touches a down dependency hangs or fails on its own, often on a timeout that takes seconds to expire. Under real traffic, that pile-up of slow failures can exhaust your server's threads before the dependency ever recovers.
Three states decide whether traffic gets through
A circuit breaker tracks recent failures against a threshold, then moves between three states. Closed is normal: requests pass through and failures are counted. Enough failures in a row, or within a window, trips it open.
Open means requests stop going out entirely. Your code gets an immediate error back instead of waiting on a timeout. The failing dependency gets a break from traffic it cannot answer anyway. After a fixed wait, the breaker moves to half-open and lets one test request through.
If that test request succeeds, the breaker closes and normal traffic resumes. If it fails, the breaker opens again and waits longer before the next test. Resilience4j and Polly, two of the more widely used breaker libraries, both implement this same three-state model.
- 01The failure threshold is usually a percentage over a rolling window, not a raw count, so five failures out of six requests trips it and five out of five hundred does not.
- 02The open-state wait is a fixed timeout, separate from the growing delays exponential backoff uses for retries. The two patterns are often paired: backoff spaces out the retries a closed breaker allows through.
- 03A breaker protects your system from a bad dependency. It does nothing for the dependency's own recovery, and it does nothing for the user waiting on an answer.
- ClosedRequests pass, failures counted.
- Threshold hitFailure rate crosses the limit.
- OpenCalls fail fast, no request sent.
- WaitFixed timeout before retesting.
- Half-openOne test request allowed through.
- Closed or openSuccess resets it, failure reopens it.
The state machine is the easy half to build. Deciding what a caller sees while the breaker is open is the half that takes a product decision.
Common questions
01How is a circuit breaker different from a retry with backoff?
Retry with backoff assumes the call is still worth attempting and spaces those attempts out over time. A circuit breaker decides the call is not worth attempting at all for now, and stops sending requests entirely. Production systems typically use both: backoff for the retries a closed breaker allows, and the breaker to stop that retrying once failures cross a threshold.
02What should a circuit breaker return when it's open?
Your team decides, based on what the request was for. Common answers are a cached or stale value, a degraded response, or a fast, clear error the caller can act on. The one wrong answer is an unhandled exception that reaches the user exactly as it would have without the breaker.
03Does a circuit breaker fix the failing dependency?
No. It protects your system from a dependency that's already failing. It also stops your retries from adding load to a service trying to recover. The dependency's own outage still has to resolve, through whoever operates it.
04How is a circuit breaker different from model fallback?
They're often paired but solve different problems. A circuit breaker decides when to stop calling a failing dependency. Model fallback is one thing it can route to once it opens: a second AI model standing in for the one that stopped responding.
Related terms
- Model fallback →What a circuit breaker routes to when the primary model stops answering.
- Exponential backoff →The retry pattern a circuit breaker most often gets paired with, and stops once it opens.
- API integration →Where failure handling like this gets built into the integration, not added after the first outage.
