Circuit Breaker
A circuit breaker stops calls to a remote service that is likely to fail. Later, a few test calls check whether it recovered.
closed -> failure threshold -> open -> cool-down -> half-open probe -> closed | open10 secondsno remote callclosed -> failure threshold -> open -> cool-down -> half-open probe -> closed | openSREAnother example
Five payment failures open the breaker for 30 seconds. Checkout fails quickly with a clear message. One later probe succeeds and closes it.
Main parts
- 01Closed state
- 02Failure counter and window
- 03Open state
- 04Cool-down time
- 05Half-open probe
- 06Fallback and alert
Use it when
Use it around a remote dependency that stays slow or broken. Tune the threshold, open time, test traffic, fallback, and alerts.
Do not use it when
Do not use it for local validation errors. It does not replace retries. Retry handles brief faults; a breaker blocks likely failures.
Name used in code
closed -> failure threshold -> open -> cool-down -> half-open probe -> closed | open Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Circuit Breaker for this system while keeping data correct, secure, and easy to operate. User context: Five payment failures open the breaker for 30 seconds. Checkout fails quickly with a clear message. One later probe succeeds and closes it. Technical concept or control: Circuit Breaker. Why it fits: Use it around a remote dependency that stays slow or broken. Tune the threshold, open time, test traffic, fallback, and alerts. Do not use it when: Do not use it for local validation errors. It does not replace retries. Retry handles brief faults; a breaker blocks likely failures. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Circuit Breaker. Definition: A circuit breaker stops calls to a remote service that is likely to fail. Later, a few test calls check whether it recovered. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.