Circuit Breaker Architecture
The circuit breaker pattern prevents a service from repeatedly attempting calls to a failing downstream dependency, allowing the dependency time to recover while failing fast to callers — similar to how an electrical circuit breaker stops current flow to prevent damage.
The circuit breaker pattern prevents a service from repeatedly attempting calls to a failing downstream dependency, allowing the dependency time to recover while failing fast to callers — similar to how an electrical circuit breaker stops current flow to prevent damage.
What the diagram shows
The diagram models the three states of a circuit breaker as a state machine. In the Closed state, requests flow normally from the calling service through the circuit breaker to the downstream service. The breaker tracks the failure rate; if it exceeds a configured threshold (e.g. 50% of the last 10 calls), the breaker trips and transitions to Open.
In the Open state, no requests are forwarded to the downstream service — the breaker returns an error immediately to the caller, preventing latency buildup and thread pool exhaustion. After a configured timeout (e.g. 30 seconds), the breaker transitions to Half-Open and allows a single probe request through. If the probe succeeds, the breaker resets to Closed; if it fails, the breaker returns to Open and resets the timeout.
Why this matters
Without a circuit breaker, a slow or failing downstream service causes the calling service's thread pool to fill with waiting connections, eventually cascading the failure to all callers — a distributed system equivalent of a stack overflow. The circuit breaker breaks that cascade by failing fast. It is a core resilience primitive in microservice architectures. For the broader resilience architecture, see High Availability System. For the retry logic that works alongside circuit breakers, see Request Retry Logic.