Circuit Breaker

Borrow the idea from your house. An electrical circuit breaker trips and cuts power when current spikes, so a short circuit does not burn the building down. A software circuit breaker does the same thing for network calls. It sits between a caller and a dependency, and when that dependency starts failing badly, it trips and stops the calls.

The reason this matters is that a slow or dead dependency is more dangerous than an obviously broken one. If service A calls service B and B takes 30 seconds to time out, A's threads pile up waiting. Each waiting request holds a connection and memory. Within seconds A runs out of threads and stops serving its own healthy traffic. Now A is down too, then whoever calls A goes down, and the failure climbs the call chain. That chain reaction is a cascading failure, and the circuit breaker exists to stop it.

Instead of letting requests hang, a tripped breaker fails fast. The call returns an error in microseconds, or returns a fallback like a cached value or a default response. The caller stays alive and responsive even though the dependency is sick.

A circuit breaker is a small state machine with three states. Closed is normal: calls pass through and the breaker counts failures. If the failure rate crosses a threshold (for example, more than 50 percent of the last 20 calls failed, or 5 consecutive failures), the breaker flips to Open.

In the Open state, no calls go through at all. Every request returns immediately with an error or a fallback, without ever touching the network. The breaker starts a timer, often 10 to 60 seconds. This is the cooldown that lets the downstream service stop being hammered and recover.

When the timer expires, the breaker moves to Half-Open. Here it lets a small number of trial requests through. If they succeed, the dependency looks healthy again, so the breaker resets to Closed. If they fail, it snaps back to Open and waits another cooldown. This trial step is what keeps the breaker from flooding a still-fragile service the instant the timer ends.

Most real implementations track failures over a rolling time window rather than a simple count, and they treat timeouts and slow responses as failures, not just thrown exceptions. They also expose metrics so you can see the breaker tripping in your dashboards.

Reach for a circuit breaker on any call that crosses a process boundary and can fail or hang: calls to another microservice, a third-party API, a payment gateway, or sometimes a database. It pairs naturally with timeouts (always set one) and retries (retry a transient blip, but let the breaker stop you from retrying a service that is clearly down).

The main trade-off is that a circuit breaker trades correctness for availability during an outage. When it is Open, callers get fallback data or errors, not the real answer. You have to decide what a sensible fallback is, and for some operations like charging a credit card there is no safe fallback, so you fail loudly instead of guessing.

Tuning is the hard part. Set the failure threshold too low and the breaker trips on a normal traffic spike, cutting off a healthy service. Set the cooldown too long and you stay degraded longer than needed. There is also a subtle trap: in a fleet of many instances each keeps its own breaker state, so behavior can look inconsistent unless you account for it.

Picture an e-commerce checkout page that shows personalized product recommendations from a separate recommendations service. One day that service starts timing out. Without a breaker, every checkout request waits the full timeout for recommendations, checkout threads exhaust, and the entire store stops taking orders over a feature nobody needs to buy.

With a circuit breaker around the recommendations call, after a handful of timeouts the breaker opens. Checkout now skips the recommendations call entirely and either shows a generic best-sellers list or hides the section. Orders keep flowing. Sixty seconds later the breaker tries one request; once recommendations recover, personalized results quietly return.

This is exactly the failure Netflix designed Hystrix to handle: isolate each dependency behind its own breaker so a single slow service can never take down the whole streaming experience.