Circuit Breaker
Also known as: breaker pattern
A circuit breaker wraps calls to a dependency and stops making them once the failure rate crosses a threshold, failing fast for a cool-down period before letting a trial request through. It converts a slow, resource-consuming failure into an immediate one and gives the struggling dependency room to recover.
Last reviewed · Part of the Architecture Glossary
In practice
Three states, and the middle one is the point:
- Closed — calls pass through; failures are counted in a rolling window.
- Open — the threshold was crossed. Calls fail immediately without touching the network, for a cool-down period.
- Half-open — after the cool-down, a small number of trial calls are allowed. Success closes the breaker; failure reopens it and usually lengthens the cool-down.
Timeouts are what make it worth having. A dependency that returns errors in 2 ms is annoying; one that hangs for a 30-second timeout is fatal, because each hung call holds a thread and a connection. At 100 req/s with a 30 s timeout you have 3,000 requests in flight against a pool of 200 — the caller dies of a dependency that never returned a single error page.
When it matters
Synchronous calls to anything you do not control: third-party APIs, another team's service, a database from a service that can degrade without it.
Common mistake
Tuning the threshold on error count rather than error rate, so a low-traffic endpoint never trips and a high-traffic one trips on noise. And opening the breaker without deciding what the fallback returns — a breaker with no graceful degradation path behind it just fails faster.
See also
- BackpressureBackpressure is the mechanism by which an overloaded component signals upstream to slow down, rather than accepting work it cannot complete.
- Graceful DegradationGraceful degradation is the property of continuing to deliver core functionality with reduced features when a dependency fails, instead of returning an error.
- Blast RadiusBlast radius is the extent of damage a single failure or change can cause — how many users, tenants, regions or services are affected when one component fails.