How many errors in a row open the breaker, and what does the state show afterwards?

Three errors in a row. After that, the state is “Open”, and calls are immediately rejected.

The breaker is closed. Two calls fail, one succeeds, then one fails. What state and counter does it show?

Closed with counter 1. Success sets the meter 0Only three errors in a row open the breaker.

The team lowers the threshold of 3 on 1. What speaks for it, what speaks against it, what do you recommend?

For this: The breaker protects the provider at the first error. On the other hand: a single temporary error then rejects all payments. Recommendation: A threshold above 1 keep and vote with the measured error rates of the provider.

PatternChapter III · Operations · Building block 4 of 10

Circuit Breaker

A Circuit Breaker observes errors of dependency and alternates between closed, open and semi-open states. In the open state, it rejects follow-up calls; after a waiting period, limited test calls check for recovery.

By Michael Meierhoff · Meierhoff Systems

ThresholdConsecutive errors open the breaker.
RejectionOpen: reject calls immediately.
ProbeA probe call decides whether to close.

Context

Why this is important

If the shop calls up a disturbed payment provider further, it extends waiting times and charges him additionally. A breaker counts errors, opens at a threshold and later checks the recovery. Bulkhead and Retry deepen.

This building block deals with state-based call limitation. Retry regulates repetitions of individual calls; Bulkhead shares resources between functions.

At a glance · Three breaker states

Too many errors open the breaker; after a waiting period, a probe call checks whether it can close again.

Shop example · Click through states

Breaker states for the payment call

The shop calls the external payment provider. After a series of technical errors, the breaker opens for further authorization attempts.

This is how you read the picture

Threshold The consecutive-error counter reaches 3; the state becomes “Open”.
Rejection In the “Open” state, the log reports “Rejected immediately; provider protected”.
Probe After “Waiting period expired”, the state becomes “Half-open” and the log reports “Probe call allowed”.

ClosedCalls pass through; consecutive errors are counted.
OpenCalls are rejected immediately; the provider remains untouched.
Semi-openThe next call is a probe that decides the next state.

Consecutive errors

Calls to Zahlungsanbieter Initiation

Trigger calls or let the waiting period expire, then observe the state and error counter.

Benefits & limitations

Helps if:

Persistent technical failures or delays tie up resources while subsequent calls continue unchecked.
A function whose business rules permit reduced functionality can continue operating in a limited form during the failure.

Boundaries

Count only technical connection failures and timeouts towards the breaker; payment rejections belong in the business rules.
A fallback such as “Payment Later” can yield outdated or incorrect results; determine when it is allowed.
The breaker limits calls to a dependency; a Bulkhead protects capacity within the shop.

In practice

Choose the scope and failures. Define the operation, dependency and technical failure types that inform state transitions. Set the minimum sample size and observation window. The breaker then opens for a relevant failure pattern while treating individual outliers appropriately.
Configure opening and probes. Set the failure threshold, open duration and number of concurrent probe calls. Explicitly define whether normal traffic returns immediately on closure or follows a separate ramp-up policy. This makes the recovery rule testable.
Test probe outcomes and recovery. Record state transitions, rejections and probe outcomes, and test transitions in both directions. Specify whether normal traffic returns immediately or follows a separate ramp-up rule. This makes the protective effect and recovery observable.

Read the detailed explanation

A circuit breaker observes calls to a defined dependency. In the closed state, traffic flows normally. When a relevant failure rate reaches a threshold within the defined window, it switches to the open state and immediately rejects subsequent calls. After a waiting period, the half-open state permits a few probe calls. The pattern complements resource limits provided by Bulkhead and the retry rules of Retry.

A successful probe closes the breaker; another failure reopens it. Failure classification, minimum sample size and scope determine whether the state transition is meaningful. A breaker controls traffic admission; business fallback and retry logic need their own handling. An additional gradual ramp-up is a separate policy that must be explicitly configured.

Michael Nygard popularised the pattern in his book “Release It!”.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
How many errors in a row open the breaker, and what does the state show afterwards?
View the solution with justification
Three errors in a row. After that, the state is “Open”, and calls are immediately rejected.
ApplyingTransferred to a new situation
The breaker is closed. Two calls fail, one succeeds, then one fails. What state and counter does it show?
View the solution with justification
Closed with counter 1. Success sets the meter 0Only three errors in a row open the breaker.
EvaluateWeighing an alternative
The team lowers the threshold of 3 on 1. What speaks for it, what speaks against it, what do you recommend?
View the solution with justification
For this: The breaker protects the provider at the first error. On the other hand: a single temporary error then rejects all payments. Recommendation: A threshold above 1 keep and vote with the measured error rates of the provider.

Explore further

These optional deepenings complement the learning goal of this page.

Fallback and Graceful Degradation

A fallback defines a replacement response permitted by the business rules; graceful degradation preserves some value with reduced functionality. In the shop, general products can replace failed personalisation while checkout remains usable. An unresolved payment outcome stays pending: the shop must not invent success or confirm the order as paid.

Define when fallback responses are fresh enough and which successful probes re-enable the normal path. The circuit breaker detects technical recovery; the application decides on the business response and return to normal operation.

For testingTest two shop cases separately. Disable personalisation and verify that product selection and checkout remain usable. Then interrupt a payment response after a possible commit: the status stays unresolved until a status query resolves it. Define which successful probes and fresh data permit normal operation to resume.

References

Continue on the learning path

Next in Runtime & operations: Bulkhead.

10 Building blocks

Continue withBulkhead