Still Active
When a downstream service fails, continuing to send requests wastes resources, increases latency, and can cascade the failure upstream. A circuit breaker detects failure patterns and short-circuits requests, giving the downstream service time to recover.
Michael Nygard introduced the circuit breaker pattern in Release It! (2007), borrowing the metaphor from electrical engineering. A circuit breaker sits between a caller and a remote dependency, tracking failure rates. When failures exceed a threshold, the breaker "opens" — subsequent calls fail immediately without contacting the downstream service.
The three states: Closed (normal operation, requests pass through), Open (failing fast, no requests sent), Half-Open (periodic test requests to check if the downstream has recovered).
Why it matters: Without a circuit breaker, a slow or failed dependency causes thread pool exhaustion in the caller. Threads block waiting for timeouts, new requests queue behind blocked threads, and the caller becomes unresponsive — even though its own code is healthy. The failure cascades from the dependency to the caller to the caller's callers.
The Ouroboros connection: Health checks and circuit breakers solve complementary problems. Health checks detect internal failure; circuit breakers protect against external failure. But both patterns can interact pathologically — a health check that probes a dependency behind an open circuit breaker will report unhealthy, triggering a restart of a healthy service.