Circuit Breaker Pattern: Fail Fast, Not Hard

Why it exists

In distributed systems, services depend on each other. If one service fails or becomes slow, its callers can get stuck waiting, consuming resources like threads and memory. This can cause the calling service to fail, which in turn causes its callers to fail, creating a cascading failure. The circuit breaker pattern exists to contain the initial failure and prevent it from spreading across the system.

The mental model

It's an electrical circuit breaker in your house's fuse box, but for software. Normally, the circuit is closed, and electricity (requests) flows freely. If there's a fault (too many failed requests), the breaker trips and opens the circuit, stopping the flow entirely. This protects the system from further damage. After a cool-down period, it cautiously tests the connection before closing the circuit again.

How it works

The pattern is a state machine that wraps a protected function call. It has three states. First, CLOSED: Requests are passed through to the downstream service. The breaker monitors for failures. If the failure count exceeds a configured threshold, the breaker trips and moves to the OPEN state. Second, OPEN: For a configured duration, all calls to the protected function fail immediately without being executed. This gives the downstream service time to recover. After the timeout expires, the breaker moves to HALF-OPEN. Third, HALF-OPEN: The breaker allows a single 'probe' request to pass through. If this request succeeds, the breaker assumes the service has recovered and moves back to the CLOSED state. If the probe fails, it returns to the OPEN state.

When to use it

Use this pattern when calling remote services over a network, especially in a microservices architecture. It's ideal for protecting your application from failures in services that are either third-party dependencies or other internal services that could be unreliable or slow. It improves system resilience by providing a fast failure response instead of a long wait.

When not to use it

It's generally overkill for in-process communication or calls to a local database. These operations typically have different, more immediate failure modes that don't benefit from this pattern's stateful, time-based logic. Also avoid it if the calling application has no reasonable fallback behavior; if failing fast just shows a user a hard error page, the benefit is reduced.

One canonical example

An e-commerce frontend calls a recommendation service. The service becomes overloaded and starts timing out. The circuit breaker, wrapping the call, notes several timeouts and trips to the OPEN state. For the next 30 seconds, any call to the recommendation service fails instantly. The frontend catches this fast failure and renders the page without recommendations, preserving the core user experience instead of making the entire site hang.