Circuit Breaker Pattern: Stop Cascading Failures

In a system made of many services, one slow dependency can drag down everything that calls it. Requests pile up waiting for responses that never come, threads and connections run out and soon services that had nothing wrong with them start failing too. The circuit breaker pattern is a standard defence. It watches calls to a dependency and, when failures cross a threshold, stops making those calls for a while and fails fast instead. This gives the struggling service room to recover and keeps the rest of the system responsive. This guide explains how the circuit breaker pattern works, how to choose its settings and how to combine it with timeouts, retries and fallbacks.

The problem: cascading failures

Microservices.io describes the problem clearly. When one service calls another that is unavailable or very slow, the caller can tie up resources waiting, which may exhaust them and leave the caller unable to handle other requests; the failure of one service can then cascade to others throughout the application (Microservices.io: Circuit Breaker).

Timeouts help, but on their own they still let every request wait for the full timeout before failing. Under heavy load, that waiting is what exhausts resources.

How the circuit breaker pattern works

Martin Fowler's description is a good starting point: you wrap a protected call in a circuit breaker object that monitors for failures, and once failures reach a threshold the breaker trips, so further calls return an error immediately without making the protected call at all (Martin Fowler: CircuitBreaker).

A circuit breaker typically has three states:

• Closed: calls pass through normally while the breaker counts failures.
• Open: calls fail immediately for a set period, without contacting the dependency.
• Half-open: after the wait, a limited number of trial calls are allowed. If they succeed, the breaker closes; if they fail, it opens again.

Microservices.io describes the same flow: after the timeout expires, the breaker allows a limited number of test requests through, and if they succeed, normal operation resumes.

Choose how to measure failure

Breakers need a rule for deciding when to trip. The Resilience4j library, for example, uses a sliding window to aggregate the outcome of calls and lets you choose a count-based or time-based window. It can trip on a failure rate threshold and also on a slow call rate, treating calls that exceed a duration as a problem even if they eventually succeed (Resilience4j: CircuitBreaker).

Counting slow calls matters. A dependency that responds, but very slowly, can do as much damage as one that fails outright.

When choosing settings, think about:

• Which errors count: timeouts and 5xx responses usually should; validation errors and 404s usually should not.
• The window size: too small and a few failures trip the breaker; too large and it reacts slowly.
• The open duration: long enough for recovery, short enough not to block a healthy service for long.
• The number of half-open trial calls.

There are no universal values. Start with conservative settings, observe real traffic and adjust.

Decide what happens when the circuit is open

Failing fast is only useful if the caller handles the failure well. Options include:

• Return a cached or default value, such as the last known exchange rate or an empty recommendations list.
• Degrade the feature, such as hiding a widget rather than failing the whole page.
• Queue the work for later, such as recording an order and confirming payment asynchronously.
• Return a clear error to the user when no fallback makes sense.

Our guide to graceful degradation explains how to design these fallbacks so users still get a working product.

Combine with timeouts and retries carefully

A circuit breaker works alongside other resilience tools, and the order matters:

• Timeouts make sure calls fail within a known time instead of hanging.
• Retries handle brief, transient errors, but should be limited and use backoff.
• The circuit breaker stops retries and new calls from hammering a dependency that is clearly down.

Without a breaker, retries can multiply load on a failing service. With one, once the threshold is crossed, calls stop until the half-open test shows recovery. Our guide to microservices communication patterns covers how synchronous and asynchronous calls affect these choices.

Worked example: breaker settings per dependency

The table below is a hypothetical set of breaker decisions for an order service that calls three dependencies. Values are placeholders that illustrate the reasoning, not recommendations.

DependencyWhat counts as failureFallback when openNotesPayment providerTimeouts and 5xx responsesHold the order as pending payment and retry laterNever assume payment succeededRecommendation serviceTimeouts, 5xx and slow callsShow no recommendationsLow business impact; trip earlyTax calculation serviceTimeouts and 5xx responsesUse cached rates and flag the order for reviewFinance agrees the fallback rule

The key is that each dependency gets settings and a fallback that match its business role. One configuration for everything usually suits nothing well.

Make breaker state visible

An open circuit is an important event. Emit metrics and logs when a breaker changes state, and show breaker status on dashboards alongside latency and error rates. Fowler notes that you will usually also want a monitor alert when the breaker trips. Without visibility, a breaker can hide a dependency outage for hours, because the calling service appears healthy while quietly serving fallbacks.

Avoid one breaker for many dependencies

Group calls carefully. If a single breaker protects calls to several different services, a failure in one can block calls to the others. Give each dependency, and sometimes each important operation, its own breaker so that trips are specific and fallbacks are accurate.

Test the behaviour

Test breakers on purpose rather than waiting for an outage. In a test environment, slow down or shut off a dependency and confirm that the breaker opens, the fallback works, alerts fire and the breaker closes again once the dependency recovers. Repeat after changes to timeouts, retry settings or fallback logic.

Where to implement it

You can implement the circuit breaker pattern in application code using a library, in a shared client used by many services or in infrastructure such as a service mesh or API gateway. Application-level breakers give the most control over fallbacks. Infrastructure-level breakers apply consistently without code changes but know less about business context. Many teams use both: infrastructure for broad protection and application code for specific fallbacks.

Frequently Asked Questions

What is the circuit breaker pattern?

It is a resilience pattern that monitors calls to a dependency and, when failures cross a threshold, stops making calls for a period and fails fast, then tests recovery before resuming.

What are the circuit breaker states?

Closed, where calls pass through; open, where calls fail immediately; and half-open, where a few trial calls test whether the dependency has recovered.

Is a circuit breaker the same as a retry?

No. Retries repeat a failed call in the hope it succeeds. A circuit breaker stops calls when failures persist, which prevents retries from overloading a struggling service.

Should every service call have a circuit breaker?

Calls to remote dependencies that can fail or slow down are good candidates. Choose settings and fallbacks per dependency based on its business importance.

Build services that fail gracefully

We design service-to-service communication with timeouts, retries, circuit breakers and sensible fallbacks. See our custom app development services, or talk to us about resilience.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.