How to Prevent Cascading Failures in Your Web Apps: The Circuit Breaker Pattern

#circuitbreaker #architecture #devops #webdev

If you have ever built or used a modern web application, you know that things break. Databases slow down, external payment APIs (Application Programming Interfaces, which are tools that let different software programs talk to each other) go offline, and third-party services lag. In a tightly connected system, a failure in one minor service can quickly spread and bring down your entire application. This domino effect is known as a cascading failure. To prevent this, software architects use a defensive strategy called the Circuit Breaker Pattern.

What is the Circuit Breaker Pattern?

The Circuit Breaker Pattern is a software design safety mechanism that monitors communication between your application and external services. If the external service starts failing repeatedly, the circuit breaker trips, immediately blocking all subsequent requests to that service and returning an instant error or a fallback response. This prevents your application from wasting system resources waiting on a dead connection. After a set cool-down period, the circuit breaker carefully lets a few test requests through to see if the target service has recovered.

The Real-World Analogy: Your Home's Electrical Box

To understand this concept, look no further than your home's electrical panel. Imagine you plug in a microwave, a toaster, and a space heater into the same outlet. If they all draw power at the same time, they will pull more electrical current than the house's wiring can safely handle.

Without a circuit breaker, the wires would overheat, melt, and potentially start a house fire. To prevent this disaster, the physical circuit breaker in your electrical panel "trips" and instantly cuts off the electricity to that room. The power stops flowing immediately, protecting your home. You cannot get electricity to that outlet again until you unplug the extra appliances (fixing the issue) and manually reset the switch. The software pattern works exactly the same way, but it resets itself automatically.

Why It Matters in Daily Software Engineering

In modern microservices—which are software systems split into dozens of small, independently running services—applications make thousands of network calls every second. Let's say your web app has a feature that shows the current weather. To do this, your server makes a request to an external weather API.

If that weather API goes down, your server's requests will hang, waiting for a response that will never arrive. Each hanging request consumes a "thread" (an individual pathway of execution that a computer processor uses to run code) and memory. If thousands of users visit your site, your server will quickly run out of threads and memory. Suddenly, your entire website crashes, and users cannot even log in or buy products—all because a non-essential weather widget failed.

Engineers use circuit breakers to protect their thread pools. Instead of waiting 30 seconds for a broken API to time out, the circuit breaker fails immediately in milliseconds, allowing the app to show a clean message like "Weather temporarily unavailable" while keeping the checkout page and login system running perfectly.

Seeing It in Action: Code

Below is a simple JavaScript implementation showing how a circuit breaker manages its states (CLOSED, OPEN, and HALF-OPEN) to protect an application.

class CircuitBreaker {
  constructor(requestFunction, failureThreshold = 3, cooldownPeriod = 5000) {
    this.requestFunction = requestFunction; // The API call to protect
    this.failureThreshold = failureThreshold; // Max failures before tripping
    this.cooldownPeriod = cooldownPeriod; // Time to wait before testing recovery
    this.state = "CLOSED"; // CLOSED means normal operation
    this.failureCount = 0;
    this.nextAttemptTime = 0;
  }

  async execute(...args) {
    const now = Date.now();

    // If the circuit is OPEN, check if the cooldown period has passed
    if (this.state === "OPEN") {
      if (now > this.nextAttemptTime) {
        this.state = "HALF-OPEN";
        console.log("Circuit is HALF-OPEN. Testing the connection...");
      } else {
        throw new Error("Circuit is OPEN. Request blocked for safety.");
      }
    }

    try {
      const result = await this.requestFunction(...args);
      this.reset();
      return result;
    } catch (error) {
      this.handleFailure();
      throw error;
    }
  }

  reset() {
    this.state = "CLOSED";
    this.failureCount = 0;
    console.log("Circuit is CLOSED. System operating normally.");
  }

  handleFailure() {
    this.failureCount++;
    console.warn(`Failure logged. Total failures: ${this.failureCount}`);
    if (this.failureCount >= this.failureThreshold) {
      this.state = "OPEN";
      this.nextAttemptTime = Date.now() + this.cooldownPeriod;
      console.error("Circuit breaker tripped to OPEN! Blocking requests.");
    }
  }
}

The Takeaway

Building resilient software is not about pretending your application will never encounter errors; it is about designing your system to fail gracefully. By incorporating the Circuit Breaker Pattern into your services, you ensure that a single broken dependency behaves like a localized blown fuse rather than a catastrophic blackout that takes down your entire company's infrastructure.

Resources

GitHub Repository: react-hook-lab
react-hook-lab: npm package
Connect with me on LinkedIn: Saurav Pandey

Originally published on my blog. You can read the alternative breakdown here.

DEV Community