A circuit breaker protects the caller from repeatedly paying the full price of a known failing dependency.

When a downstream service is timing out or failing consistently, blindly sending more traffic often makes the whole platform worse. The Circuit Breaker pattern detects unhealthy dependency behavior and temporarily fails fast, giving the caller a chance to degrade gracefully, retry later, or route work differently.

OOAD landing page Learning roadmap Previous: Service Mesh Next: Bulkhead and Retry

Why This Topic Matters

Why it matters in real Java systems

If shipment estimates are slow or unavailable, checkout should not let every request thread pile up waiting on the same broken dependency. A circuit breaker can preserve responsiveness and protect upstream capacity while the downstream recovers.

Core Explanation

The main design idea

Circuit breakers usually track failure rates or timeout counts and move between closed, open, and half-open states. Closed means normal traffic flows. Open means requests fail fast for a time window. Half-open allows limited probes to test recovery. This is fundamentally a capacity-protection pattern, not a business consistency pattern.

The circuit breaker helps the platform survive dependency failure. It does not decide whether a fallback result is business-acceptable. That decision belongs to the application and domain context.

Concept Breakdown

Key ideas to keep in mind

Concept

Fail fast under known failure

Do not keep exhausting threads on a dependency that is already unhealthy.

Concept

Protect upstream capacity

The caller remains more available by limiting pointless waiting.

Concept

Needs good fallback judgment

Returning stale shipping estimates may be acceptable; faking payment success is not.

Circuit breaker states

State	Meaning
Closed	Normal operation; failures are still below the threshold
Open	Dependency is considered unhealthy; calls fail fast temporarily
Half-open	Limited requests test whether the dependency has recovered

Java Example

Java example in the Order Management domain

Java example: fast-fail around an unstable dependency

package org.javaomnibus.checkout;

public final class ShippingEstimateService {
    private final CircuitBreaker circuitBreaker;
    private final ShippingClient shippingClient;

    public ShippingEstimateView estimate(DeliveryAddress address) {
        return circuitBreaker.execute(
            () -> shippingClient.estimate(address),
            () -> ShippingEstimateView.unavailable("Estimate temporarily unavailable")
        );
    }
}

Code Walkthrough

Step by step

The fallback is explicit and intentionally limited to a use case where temporary unavailability can be tolerated.
The breaker protects the caller from repeatedly waiting on a failing dependency.
In a stronger business path such as payment authorization, the fallback would likely be an explicit failure state rather than synthetic success.
This is why resilience patterns always need domain judgment alongside platform mechanics.

Real-World Usage

Where this helps in practice

Protecting upstream services from slow downstream dependencies
Reducing thread exhaustion during service incidents
Supporting graceful degradation in non-critical parts of the user journey

Trade-Offs

Trade-offs and when to be careful

Circuit breakers improve platform resilience, but they can hide chronic dependency issues if teams only watch short-term recovery behavior.
Poorly designed fallbacks can create misleading user experiences or incorrect business assumptions.

Common Mistakes

Frequent mistakes to watch for

Using the same fallback strategy for every business operation
Setting thresholds without observing real traffic patterns
Relying on circuit breakers while ignoring root-cause dependency health
Combining aggressive retries with circuit breaking in ways that still overload downstreams

Related concepts

Bulkhead and Retry Distributed system failures API Gateway pattern