Python Circuit Breaker Pattern — Core Concepts

What Is the Circuit Breaker Pattern?

The circuit breaker pattern prevents an application from repeatedly calling a service that’s likely to fail. Instead of letting failed calls pile up (consuming threads, connections, and user patience), the circuit breaker fails fast and gives the struggling service time to recover.

Michael Nygard popularized this pattern in his book Release It! (2007), and it’s now a standard resilience pattern in distributed systems.

The Three States

A circuit breaker has three states, like a traffic light:

Closed (Normal Operation)

Requests flow through normally. The circuit breaker monitors failures in the background. If the failure rate stays below the threshold, nothing changes.

Open (Tripped)

Too many failures occurred. The circuit breaker stops forwarding requests entirely. Instead, it immediately returns an error or a fallback value. No network call is made.

The circuit stays open for a configured timeout period (e.g., 30 seconds). This gives the failing service time to recover without being hammered by more requests.

Half-Open (Testing Recovery)

After the timeout, the breaker enters half-open state. It allows a limited number of test requests through. If these succeed, the circuit closes (back to normal). If they fail, it opens again for another timeout period.

When Does It Trip?

Common triggers:

• Failure count — Trip after 5 consecutive failures
• Failure rate — Trip when more than 50% of recent requests fail
• Slow calls — Trip when response times exceed a threshold (e.g., 10 seconds)

The threshold and time window are configurable. A payment service might trip after 3 failures (low tolerance), while a recommendation engine might tolerate 10 failures before tripping (higher tolerance for a non-critical service).

Why Not Just Retry?

Retries and circuit breakers solve different problems:

Retries handle transient failures — a single dropped connection, a momentary timeout. They assume the next attempt will likely succeed.

Circuit breakers handle sustained failures — a service is down, overloaded, or experiencing a prolonged outage. They assume the next attempt will probably fail too.

They work best together: retry a few times, and if the failure persists, the circuit breaker trips to prevent further retries from piling up.

Fallback Strategies

When the circuit is open, you need a plan:

• Cached data — Return the last known good response from cache
• Default values — Return sensible defaults (empty recommendations, estimated shipping times)
• Degraded experience — Show a simplified version of the page without the failing service’s data
• Queue for later — Accept the request and process it when the service recovers

The right fallback depends on the service. A broken image service might show placeholders. A broken payment service has no safe fallback — you must tell the user to try again later.

Where Circuit Breakers Shine

Microservice architectures — Service A calls Service B, which calls Service C. If Service C is down, without circuit breakers, the failure cascades: Service B’s threads block waiting for C, then Service A’s threads block waiting for B. The entire system freezes.

Third-party API calls — External APIs have outages, rate limits, and degraded performance you can’t control. A circuit breaker protects your app from depending too heavily on their availability.

Database connections — When the database is overwhelmed, continuing to open new connections makes it worse. A circuit breaker on the connection layer lets the database recover.

Common Misconception

“Circuit breakers replace monitoring.” A circuit breaker is a runtime protection mechanism, not a monitoring tool. You still need alerts when a circuit trips. In fact, a tripped circuit breaker is one of the most important signals to monitor — it means a dependency is failing and user experience is degraded. Always emit metrics when the state changes.

The one thing to remember: A circuit breaker has three states — closed (normal), open (failing fast), and half-open (testing recovery) — and prevents one broken service from cascading into a system-wide outage.