What is the circuit breaker pattern and what does it do in software?

The circuit breaker is a software resilience pattern that monitors calls to an external service and, once a failure threshold is crossed, automatically stops subsequent calls instead of letting them wait for a timeout. The name comes from the electrical switch: just as it protects a circuit from overload by opening, this protects the calling system from a service that is already struggling. The mechanism has three states. Closed: calls pass through normally and the breaker counts failures. Open: once the threshold is exceeded, every call fails immediately or returns a fallback, without contacting the service, for a cooldown period. Half-open: after that period, the breaker lets a limited number of trial calls through; if they succeed it closes again, otherwise it reopens. The pattern was described by Michael Nygard in the book Release It! (2007) and from there entered distributed resilience libraries, such as Netflix's Hystrix, historically, and more recently Resilience4j.

Why a timeout with retries is not enough

A timeout with blind retries makes the problem it is meant to solve worse: if an external service is already slow or overloaded, every call that waits for the timeout before retrying ties up threads, connections and memory in the calling system, and the retries add further traffic to a service that is already struggling to respond. The circuit breaker prevents the cascading effect: as soon as it recognizes the failure pattern, it stops waiting and retrying, freeing its own system's resources and giving the downstream service time to recover without added pressure. It is a runtime mechanism, not a code design choice: it sits at the point where the system calls the external one, typically as a wrapper around the HTTP or RPC client, and it is complementary to patterns such as observability of downstream calls, which it relies on to know when to open the circuit.

An enterprise example

A company integrating a third-party payment service into its checkout flow, without a circuit breaker, is exposed to a single point of external slowness: if the payment provider starts responding in ten seconds instead of two hundred milliseconds, every checkout request sits in queue waiting for that response, and server threads blocked on the wait pile up until the connection pool is exhausted. At that point even pages that do not depend on payment, such as the catalog or the cart, stop responding, because no free resources remain to serve them. With a circuit breaker configured on the call to the payment service, after a few consecutive failures the circuit opens: checkout requests get an immediate error or unavailability message instead of hanging, and the rest of the site keeps working normally while the provider recovers.

Why it matters for decision makers

Every critical integration with an external service, whether payment, identity, or a third-party API, carries the risk that its own slowdown propagates into the system calling it. The circuit breaker is the standard runtime mitigation for that risk: it does not remove the dependency on the vendor (that is assessed with vendor lock-in), but it stops a vendor's incident from becoming your own. It is a low-cost investment to implement, often already available in the resilience libraries of the language in use, and its absence is almost always invisible until the vendor's first outage, when the difference is between a contained error and a total service disruption.