← Back to Learn
Intermediate7 April 20263 min read

Circuit Breaker Pattern — The MCB of Your Microservices

When a downstream service is failing, should you keep calling it? The Circuit Breaker pattern prevents cascading failures — just like the MCB in your house.

circuit-breakerresiliencemicroservices
Share:

The MCB Analogy

Every Indian house has an MCB (Miniature Circuit Breaker) in the electrical panel. When there's a short circuit or overload, the MCB trips and cuts power to that circuit — protecting the rest of your house from damage.

Without an MCB, a short circuit in your kitchen could fry every appliance in your house.

The Circuit Breaker Pattern does the same thing for microservices. When a downstream service is failing, the circuit breaker "trips" and stops sending requests to it — protecting the rest of your system from cascading failures.

The Problem: Cascading Failures

User → Order Service → Payment Service (DOWN! 🔥)
                            ↓
                    Order Service waits... waits... timeout (30s)
                            ↓
                    User waits 30 seconds for "Error"
                            ↓
                    1000 users waiting = 1000 threads blocked
                            ↓
                    Order Service runs out of threads
                            ↓
                    Order Service ALSO goes down! 🔥🔥
                            ↓
                    Now User Service can't reach Order Service
                            ↓
                    ENTIRE SYSTEM DOWN! 🔥🔥🔥

One failing service took down the entire system. This is a cascading failure.

How Circuit Breaker Works

The circuit breaker has three states:

1. CLOSED (Normal)

Everything is working. Requests flow through normally.

Request → Circuit Breaker [CLOSED] → Payment Service ✅

2. OPEN (Tripped)

Too many failures detected. Circuit breaker stops all requests immediately and returns a fallback response.

Request → Circuit Breaker [OPEN] → ❌ Instant failure response
                                    (doesn't even call Payment Service)

3. HALF-OPEN (Testing)

After a timeout, the circuit breaker lets ONE request through to test if the service has recovered.

Request → Circuit Breaker [HALF-OPEN] → Payment Service
   ↓                                         ↓
If success → Back to CLOSED              If fail → Back to OPEN

The State Machine

         success
    ┌──────────────┐
    ▼              │
┌────────┐    ┌────┴─────┐    ┌────────┐
│ CLOSED │───→│ OPEN     │───→│HALF-OPEN│
│        │    │          │    │         │
└────────┘    └──────────┘    └────┬────┘
  failures      timeout           │
  exceed        expires        success → CLOSED
  threshold                    failure → OPEN

Real-World Example: Swiggy

When you order on Swiggy, the app calls multiple services:

App → Restaurant Service ✅
App → Payment Service ✅
App → Delivery Service ❌ (overloaded during rain)

Without circuit breaker: Every order request waits 30 seconds for Delivery Service, then fails. Users see a spinning loader.

With circuit breaker: After 5 failures, the circuit opens. New requests instantly get: "Delivery partners are busy. We'll assign one shortly." The order is placed, and delivery is assigned asynchronously when the service recovers.

Configuration Parameters

Failure threshold: How many failures before opening (e.g., 5 failures in 60 seconds)
Timeout duration: How long to stay open before trying again (e.g., 30 seconds)
Success threshold: How many successes in half-open before closing (e.g., 3 consecutive successes)

Key Takeaway

Circuit Breaker = "Fail fast, recover gracefully." Instead of waiting for a dead service and blocking everything, fail immediately and try again later. It's essential for any microservices architecture. In interviews, mention it whenever you discuss service-to-service communication.

👨‍💻
Sahil Sudan

Software Engineer at Spense. I write about system design, web development, and fintech — explained simply for students and developers.

📬 Stay Updated

Get a new System Design or fintech insight every week. No spam, unsubscribe anytime.

Share: