In distributed systems, dependencies fail.

A payment gateway becomes unresponsive. An internal service returns errors. A database cluster enters a degraded state.

The instinctive response is to retry. Exponential backoff softens the impact, but repeated attempts still consume resources. If every request continues to call a failing service, the failure spreads.

Threads block waiting on timeouts. Connection pools fill. CPU usage climbs. A localized problem turns into a system-wide incident.

The Circuit Breaker pattern introduces a deliberate pause.

Recognising Repeated Failure

A circuit breaker monitors calls to a dependency. When failures cross a defined threshold, it changes state.

Instead of continuing to call the failing service, the circuit opens. Requests fail fast. The system stops sending traffic to the dependency for a cooldown period.

During this time, resources are preserved. Threads are not tied up waiting for timeouts. The dependency has space to recover.

After the cooldown, the breaker transitions to a half-open state. A limited number of trial requests are allowed through. If they succeed, the circuit closes and normal traffic resumes. If they fail, the breaker opens again.

The pattern introduces feedback into the system’s behaviour.

Failing Fast to Stay Healthy

Failing fast can feel uncomfortable. It means some requests are rejected immediately instead of being retried.

Yet failing fast is often healthier than waiting.

When a dependency is clearly unavailable, additional calls do not improve the outcome. They increase load and extend the outage. The circuit breaker protects both the caller and the callee.

It prevents a retry storm from forming. It reduces cascading failure. It limits the blast radius of a problem.

Tuning and Tradeoffs

Circuit breakers require thresholds. How many failures trigger an open state? How long is the cooldown? How many test requests are allowed in half-open mode?

These values depend on traffic patterns and tolerance for failure. Poor tuning can lead to premature trips or delayed protection.

Some requests will fail quickly during an outage. That is a deliberate choice. The system chooses stability over prolonged waiting.

In exchange, the overall service remains responsive.

Where It Fits

Circuit breakers are valuable around remote calls: HTTP APIs, databases, message brokers, and other networked services.

They are less relevant for purely local operations that fail instantly and predictably.

The pattern works best in combination with retries and backoff. Backoff manages individual request pacing. The circuit breaker manages systemic failure.

A Controlled Boundary

Electrical circuits use breakers to prevent damage when current spikes.

Distributed systems use circuit breakers to prevent damage when errors spike.

The goal is containment.

When one dependency fails, the rest of the system should remain steady.

Sometimes the healthiest action is to stop trying for a while.