Circuit Breaker Pattern
Circuit Breaker: start from the problem
See the responsibilities
A dependency is repeatedly failing while callers continue to spend workers and time on it. A circuit breaker can reduce repeated calls during that unhealthy period and allow controlled probes later.
This is a workflow and resilience pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Circuit Breaker addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
A breaker records outcomes and follows a state policy. Closed permits calls. Open rejects or uses a defined fallback without calling the dependency. Half-open allows limited probes; their observed outcomes decide whether normal calls resume.
Our small example opens after two failures and skips a third call. It has no clock or half-open probes. The state exercise explains the fuller policy; production thresholds and transitions must be measured and supported by the implementation.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
let failures = 0;
let open = false;
function callDependency() {
if (open) return 'skipped';
failures++;
if (failures >= 2) open = true;
return 'failed';
}
console.log(callDependency());
console.log(callDependency());
console.log(callDependency());Expected output
failed
failed
skippedChoose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it when repeatedly calling an unhealthy dependency worsens resource use and there is a truthful rejection or fallback contract.
A breaker does not repair the dependency, undo a payment or prove an earlier request failed. Shared state and noisy thresholds can cause avoidable rejection. Bound probes and do not return a fallback that violates the operation’s correctness promise.
Distinguish the neighbouring patterns
Retry repeats a selected operation under a budget. Circuit Breaker gates calls based on observed health. Bulkhead isolates resource pools; the three policies can work together.
Follow deadlines and outcome uncertainty, bounded repeated attempts, resource isolation to compare the specific responsibility before combining patterns.
For further reading, use Microsoft’s Circuit Breaker guidance. Compare it with this original example and the guarantee required by your application.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Circuit Breaker, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside resource isolation.
Reaching the recap and completing the quizzes are separate milestones.