Circuit breaker
Circuit breaker
Gold
A circuit breaker watches calls to a dependency. After too many failures it opens and fails fast for a while, then lets a few trial calls through to check whether the dependency has recovered.
- Use when
- Calls to dependencies that can fail or slow down · Shielding a struggling service from a flood of retries
- Avoid when
- In-process calls · When waiting for the breaker to reset would be an unacceptable delay · As a substitute for handling errors in the calling code
- Trade-offs
- Fails fast and protects resources, but rejects some calls that might have worked · Thresholds need tuning per dependency
- Requires
- Retries with backoff and jitter
3 objectives · 7 misconceptions
- explain Explain the closed, open and half-open states and what moves the breaker between them.
- predict Predict caller latency and load on a failing dependency with and without a breaker.
- choose Choose a fallback — cached value, default or error — for when the breaker is open.
- Not true: A circuit breaker fixes the failing dependency.
- Not true: With a circuit breaker you do not need timeouts.
- Not true: A breaker lets calls through again the moment the dependency recovers.
- Not true: An open breaker still sends every call to the dependency, it just reports the errors.
- Not true: Any fallback is fine, as long as the page still loads.
- Not true: A half-open breaker lets a large share of traffic through to test the dependency.
- Not true: When an optional feature's breaker is open, the whole page should fail.