Protocol
Open the circuit when a dependency keeps failing
Sometimes the kindest request to a failing service is the one you do not send.
When it fits
- A dependency is persistently failing or timing out and retries add more load without useful progress.
When to avoid it
- Circuit breakers can block a recovered service if thresholds or probe logic are poor; tune and monitor them.
Why it matters
Track recent dependency failures. When failure crosses the defined threshold, stop normal calls temporarily and fail or degrade locally. After a recovery interval, allow a small number of probe calls before reopening normal traffic. Make breaker state visible to operators.
Steps
- Failure threshold is defined.
- Open state stops normal calls.
- A fallback or explicit failure path exists.
- Half-open probes are limited.
- Successful probes close the circuit.
- Breaker state and transitions are observable.
An example
An agent stops calling a failing external search service after repeated timeouts and periodically tests recovery with one low-rate request.
Check your result
A persistently failing dependency cannot trigger unlimited retries from every caller.
Keep this limit in mind
- Circuit breakers can block a recovered service if thresholds or probe logic are poor; tune and monitor them.
Connected ideas
Useful withDefine the cheaper mode that preserves the core function
Evidence and sources
Supports
Circuit breakers stop repeatedly failing calls to an unhealthy dependency and later allow limited probes to detect recovery.
Poor thresholds can open unnecessarily or delay recovery; breaker state needs observability.
Circuit breaker pattern · Intent and open/half-open/closed states