We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Microservices Architecture
A pattern that stops calling a failing service after repeated failures, preventing cascade failures. Like an electrical circuit breaker that cuts power to prevent fires.
In short
A circuit breaker is a resilience pattern that wraps calls to a remote service, watches them fail, and once failures cross a threshold it stops sending requests for a cooldown period and immediately returns an error or fallback instead. This protects the caller from wasting resources on a service that is already down and gives the failing service room to recover, preventing one outage from cascading across a system.
In short
A circuit breaker is a resilience pattern that wraps calls to a remote service, watches them fail, and once failures cross a threshold it stops sending requests for a cooldown period and immediately returns an error or fallback instead. This protects the caller from wasting resources on a service that is already down and gives the failing service room to recover, preventing one outage from cascading across a system.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Circuit Breaker across a run of lessons, not one page. These 3 alone are about 130 minutes of step-by-step reading, 1 of them with code you run in the browser, all with a quiz.
Prevent cascading failures in distributed systems by failing fast when a downstream service is unhealthy.
Design an API gateway - request routing, authentication, rate limiting, circuit breaker, load balancing, and observability.
Stop calling failing services to prevent cascade failures, open, closed, and half-open states.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Circuit Breaker Patternpay once,
yours for life
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.
Netflix Hystrix
Pioneered the pattern at scale, wrapping every inter-service call in its own breaker with a fallback so one failing dependency could not collapse streaming. Now in maintenance mode and superseded by Resilience4j.
Resilience4j
The modern Java library most teams use today, providing a lightweight circuit breaker plus retry, rate limiter, and bulkhead modules.
Istio and Envoy
Service meshes enforce circuit breaking at the network proxy layer, so the pattern works for any language without changing app code.
AWS App Mesh
Applies outlier detection and connection limits per service to trip traffic away from unhealthy instances automatically.
A retry assumes the failure is a brief blip and tries the same call again. A circuit breaker assumes the dependency is genuinely down and stops calling it for a while. They work together: retry a transient error a couple of times, but if failures keep coming, the breaker opens and prevents pointless retries that only add load to a dying service.
Closed, where calls pass through normally and failures are counted; Open, where the breaker has tripped and all calls fail fast without hitting the network; and Half-Open, where after a cooldown a few trial calls are allowed through to test whether the dependency has recovered before fully closing again.
There is no universal number, you tune from real traffic. A common starting point is opening at a 50 percent failure rate over a rolling window of 20 or more calls, with a cooldown of 10 to 60 seconds. Set the threshold high enough that normal noise does not trip it, and the cooldown long enough for the downstream service to actually recover.
No. It contains the damage so a failing dependency does not take down healthy services, and it buys the failing service time to recover, but it does not repair the dependency. You still need monitoring, alerts, and a real fix for the root cause. The breaker is damage control, not a cure.
On the caller side, around the outbound call to the dependency. It can sit in application code via a library like Resilience4j, or in infrastructure via a service mesh proxy like Envoy. The mesh approach keeps your application code clean and works across languages, while the library approach gives finer control over fallbacks.
Bulkhead
A pattern that isolates different parts of a system so a failure in one part doesn't sink the whole ship. Named after the compartments in a ship's hull.
Retry
Automatically re-attempting a failed operation, usually with exponential backoff. Essential for handling transient failures in distributed systems.
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
Timeout
A maximum duration to wait for an operation to complete before giving up. Without timeouts, a stalled dependency can hang your entire system indefinitely.
Monolith
A single, unified application where all features share the same codebase and deployment. Simpler to start with but harder to scale individual parts.
Service Discovery
The mechanism by which microservices find and communicate with each other. Services register themselves and others can look them up by name.
This page explains the idea. The "Circuit Breaker Pattern" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Circuit Breaker Pattern lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Circuit Breaker in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
