Circuit Breaker
A safety switch that stops calls to a failing service for a while, then sends a small probe to see whether it has recovered.
See it
What it is
A circuit breaker watches calls to a dependency and stops sending them after failures cross a threshold. It is closed while calls flow, open while calls fail immediately, and half-open when a small probe is allowed through to see whether the dependency recovered. The name and the states come from Michael Nygard's book Release It!, and Netflix's Hystrix library made the pattern famous in service architectures.
Reach for one around a remote service whose slow failure can consume threads, sockets, or the whole request budget. Failing fast protects your own capacity and gives the dependency room to recover. Pair it with strict timeouts and a fallback only when stale or partial data is honestly acceptable.
A breaker is not a retry loop. Retrying can add pressure; opening a breaker removes it. Thresholds that are too sensitive flap on tiny samples, while thresholds that are too loose react after the damage is done. Track open, half-open, rejected, and recovery events, and remember that one in-process breaker sees only one instance's traffic.
Ask AI for it
Wrap this downstream client with a Resilience4j CircuitBreaker. Use a count-based slidingWindowSize of 20, minimumNumberOfCalls of 10, failureRateThreshold of 50, and waitDurationInOpenState of 30 seconds. Allow 3 half-open probe calls, count timeouts and 5xx responses as failures, ignore validation errors, and emit metrics for every state transition. Add tests for closed-to-open, fail-fast while open, half-open recovery, and a failed probe reopening the circuit.