Circuit Breaker

If a downstream dependency is slow or failing and callers keep sending requests the same way, the caller's own resources start getting trapped too. Blind retries can make the incident worse by increasing load and waiting time. That is how one partial outage can spread into thread-pool exhaustion, queue buildup, and broader unavailability. Circuit Breaker exists to interrupt that chain before it widens.

As systems became more networked and dependency-heavy, partial outages became common. A single slow dependency could pull many healthy services into distress if they kept waiting, retrying, and holding resources open. Simple timeouts were not always enough to protect the rest of the platform. That is why intentionally cutting off a failing dependency for a period became a standard resilience tactic.

At first, calls are allowed through normally. If failures or timeouts cross a threshold, the circuit opens and blocks real calls for a while, often failing fast or returning a fallback instead. After a cooldown period, a small number of requests are allowed through in a Half-Open state to test recovery. If they succeed, the circuit closes again.

Circuit Breaker and Saga both address distributed failure, but Circuit Breaker protects the call path while Saga governs the state of a multi-step business workflow. Circuit Breaker and Idempotency also differ: Circuit Breaker decides whether to send a call at all, while Idempotency makes repeated execution safe if the same request is sent more than once. Compared with Observability, Circuit Breaker is an active protection mechanism while Observability makes the system legible.

Circuit Breaker is useful on remote calls to internal services, external APIs, and other networked dependencies where fast failure is safer than repeated waiting. It works best when thresholds and cooldowns are based on observed behavior rather than guesswork. In practice, this means Circuit Breaker and telemetry must be operated together.