Circuit Breaker Pattern

The Electrical Panel Analogy

Think about the electrical panel in your house.

If there is a sudden power surge or you plug too many high-wattage appliances into one outlet, the wires could overheat and cause a fire. To prevent this catastrophic failure, a circuit breaker sits between the power grid and your house.

When it detects a dangerous surge, the breaker "trips" (opens the circuit), immediately cutting off electricity. Once you fix the problem, you reset the switch (closing the circuit), and power flows normally again.

In distributed software systems, we use the exact same concept to prevent catastrophic cascading failures.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

CLOSED state: Normal operation. Requests flow through the breaker to Stripe. The breaker silently tracks the failure rate. If failures exceed the threshold (e.g., 50% over 10 seconds), it trips to OPEN.

1 / 10.5×1×2×3×Playground

CLOSED: requests pass through normally. | OPEN: breaker trips, returns error immediately without a network call. | HALF-OPEN: test requests check if the service recovered.

What is the Circuit Breaker Pattern?

In a microservices architecture, services constantly call other services. For example, your CheckoutService calls a third-party StripePaymentAPI.

What happens if Stripe goes down and takes 30 seconds to respond to a request before timing out?

If your system keeps sending requests to Stripe, your CheckoutService will quickly run out of threads waiting for responses. Soon, your CheckoutService crashes. Because it crashed, the CartService waiting on it also crashes. Before you know it, one slow third-party API has taken down your entire application.

The Circuit Breaker Pattern stops this. It wraps the API call in a proxy monitor that tracks failures.

The Three States

A software circuit breaker operates in three distinct states:

1. Closed (Normal): Requests flow through freely. The breaker counts successes and failures. If the failure rate (e.g., timeouts or 500 errors) exceeds a certain threshold (say, 50% failures over 10 seconds), the breaker trips.
2. Open (Failing): The circuit is broken. If your application tries to call the API, the circuit breaker immediately returns an error (or a fallback response) without actually making the network call. This gives the struggling downstream service time to recover and prevents your app from wasting resources waiting on a dead service.
3. Half-Open (Testing): After a timeout period, the breaker allows a limited number of test requests to pass through to see if the downstream service is back online.
   • If the test requests succeed, the breaker resets to Closed.
   • If they fail, it trips back to Open and waits again.

Real-World Example: Netflix Hystrix

Netflix popularized this pattern with an open-source library called Hystrix (though today, tools like Resilience4j are more common).

When you load Netflix, the backend calls a RecommendationService to get your personalized movie list. If that service is struggling under heavy load, the circuit breaker trips.

Instead of showing you a broken webpage or spinning forever, the circuit breaker immediately returns a fallback. The fallback might just be a hardcoded list of the "Top 10 Global Trending Movies." As a user, you still get a working page with movies to watch, and the system is saved from a cascading outage.

Summary

The Circuit Breaker pattern prevents cascading failures in distributed systems. By failing fast when a downstream service struggles, it protects your threads from exhaustion and gives the failing service room to recover. A good fallback response means users see a degraded experience rather than a complete outage.