A Three-State Sheet for Taming a Supplier Lookup That Keeps Failing

Suppose your product page or quoting tool asks a supplier for availability. When the supplier slows down, every visitor waits, your workers pile up, and retries add load to a service that is already struggling. A circuit breaker limits that damage. This is a conditional design proposal, and every number below is a placeholder to tune, not a recommendation of specific values.

When this applies

Use it only for a lookup, meaning a read with no side effects. If the call also creates an order or reserves stock, a breaker alone is not enough. Never automatically repeat a write whose outcome is uncertain. Check the resulting state first.

Primary artifact: the transition sheet

Fill in one sheet per dependency.

State	Behaviour	Leaves this state when
Closed	Calls go through. Failures are counted.	Failure count reaches the threshold within the window, so it goes to Open.
Open	No calls to the supplier. Return the fallback at once.	The cool-down timer expires, so it goes to Half-open.
Half-open	Allow a small fixed number of probe calls. Everything else gets the fallback.	All probes succeed, so Closed. Any probe fails, so Open with the timer restarted.

Also write down:

What counts as a failure: timeouts and server-side error responses.
What does not count: responses showing that our own request was malformed, since those point at our bug and not at the supplier.
The fallback: for example "availability unconfirmed, we will check and reply".

Decision branches

Supplier slow or down: counts toward opening.
Supplier rejects our request shape: does not count. Fix the request and alert a developer.
Supplier answers but returns "no stock": a successful call with a business answer, not a failure.

Worked hypothetical timeline

Placeholders: threshold 5 consecutive failures, cool-down 60 seconds, 2 probes.

Calls 1 to 3 time out. Count is 3, still Closed.
Call 4 succeeds. Because the threshold counts consecutive failures, the count resets to 0.
Calls 5 to 9 time out. That is 5 consecutive failures, so the state becomes Open.
For the next 60 seconds, 12 visitors request availability and all 12 receive the fallback. Supplier calls made: 0.
At 60 seconds the state becomes Half-open. Probe 1 succeeds and probe 2 times out. One failed probe returns the state to Open with a fresh 60-second timer.
After the second cool-down, probe 1 and probe 2 both succeed, so the state returns to Closed with the count at 0.

Check the counts: 9 calls to the supplier before opening, 0 while open, 2 probes in the first half-open phase, and 2 probes in the second. Both phases are accounted for.

Stop conditions

Pause the breaker design and review by hand if:

The lookup turns out to have side effects.
Fallback answers are being treated by staff as confirmed availability.
The breaker flips between Open and Half-open continually. The cool-down may be too short, or the dependency may need a longer manual pause.

Proposed acceptance tests (not yet performed)

With a fake supplier that always times out, the state opens after exactly the threshold number of consecutive failures.
While Open, the fake supplier records zero calls.
In Half-open, concurrent visitors beyond the probe allowance get the fallback and never reach the supplier.
A malformed-request response does not change the failure count.
A success in the Closed state resets the consecutive count.
The fallback text never states availability as confirmed.
State changes are logged with a timestamp so staff can see why answers changed.

A breaker is one constraint among several. Combine it with a per-call timeout and a cap on concurrent lookups. None of these makes the supplier reliable. They only keep your own site usable while it is not.