Circuit Breaker Pattern — Resilience, Fallbacks (2026)

In this tutorial, you'll learn how the circuit breaker pattern prevents cascading failures in distributed systems, how it transitions between closed, open, and half-open states, and how real applications degrade gracefully when services fail.

A circuit breaker in your house does one job: if too much current flows, it trips and cuts power. It doesn't try to keep the lights on while the wiring is melting. It stops, waits, then tests whether the fault is fixed. Software circuit breakers work the same way — when a service starts failing, they stop sending requests to it, give it time to recover, and periodically check if it's healthy again.

Core Concept

The circuit breaker pattern prevents an application from repeatedly trying an operation that's likely to fail. Instead of wasting resources on doomed requests, it fails fast and provides a fallback response. This prevents cascading failures — one slow service can't bring down the entire system.

Three states govern the circuit breaker:

                  Threshold exceeded
    ┌──────────┐ ──────────────────→ ┌──────────┐
    │  CLOSED  │                     │   OPEN   │
    │ (normal) │                     │ (blocked)│
    └──────────┘ ←────────────────── └──────────┘
                  Timeout elapsed      │
                       │               │
                       │    Success    │
                       └──→ ┌──────────┐
                            │HALF-OPEN │
                            │ (probing)│
                            └──────────┘
                                  │
                            Failure → back to OPEN

How It Works

Every failure increments a counter. When the counter hits a configurable threshold within a time window, the circuit trips to open. After a timeout, it transitions to half-open and sends a probe request. If the probe succeeds, the circuit closes. If it fails, it opens again.

class CircuitBreaker {
  private state: "closed" | "open" | "half-open" = "closed";
  private failureCount = 0;
  private lastFailureTime = 0;
  private readonly threshold = 5;
  private readonly timeout = 30000; // 30 seconds

  async call<T>(action: () => Promise<T>, fallback: () => T): Promise<T> {
    if (this.state === "open") {
      if (Date.now() - this.lastFailureTime > this.timeout) {
        this.state = "half-open";
      } else {
        return fallback(); // Fail fast
      }
    }

    try {
      const result = await action();
      this.onSuccess();
      return result;
    } catch (error) {
      this.onFailure();
      return fallback();
    }
  }

  private onSuccess() {
    this.failureCount = 0;
    this.state = "closed";
  }

  private onFailure() {
    this.failureCount++;
    this.lastFailureTime = Date.now();
    if (this.failureCount >= this.threshold) {
      this.state = "open";
    }
  }
}

Usage with fallback

const breaker = new CircuitBreaker();

async function getUserProfile(userId: string) {
  return breaker.call(
    // Primary action
    () => userService.fetchProfile(userId),
    // Fallback — return cached or default data
    () => ({
      id: userId,
      name: "Unavailable",
      message: "Profile service is temporarily down"
    })
  );
}

Expected output: When the user service is healthy, the profile is fetched normally. When it fails 5+ times, subsequent calls return the fallback instantly without waiting. After 30 seconds, one probe request checks if the service recovered.

Real-World Examples

Anti-Virus Cloud Lookups

Durga Antivirus Pro uses a circuit breaker for cloud-based threat intelligence lookups. If the cloud service is unreachable or returns errors, the circuit opens and scans fall back to local signature databases. Users still get protection — just without the latest cloud updates until the service recovers.

Payment Gateway Integration

E-commerce platforms integrate multiple payment providers. A circuit breaker around a failing payment gateway (e.g., timeout errors) automatically switches traffic to the backup provider. Customers complete their purchase without seeing an error page.

Bulkhead Isolation

Closely related to circuit breakers, bulkhead isolation separates resources into pools so a failure in one doesn't starve others. Netflix's Hystrix assigns each service dependency its own thread pool — if one pool exhausts its threads, other services are unaffected.

Pros & Cons

When to Use

Use circuit breakers when:

• Your application calls external services over a network (other microservices, third-party APIs, databases)
• Failures are transient — the service may recover after seconds or minutes
• You need graceful degradation — failing fast with a fallback is better than hanging indefinitely
• You want to prevent resource exhaustion — thread pools, connection pools, and memory can fill up waiting for failing calls

Skip it for local function calls (failures there are bugs, not transient), or when the cost of the fallback is higher than the cost of retrying.

FAQ