Circuit breaker pattern in system design

A circuit breaker protects your service from repeatedly calling a dependency that is already failing.

Instead of letting every request wait on a slow or broken service, the circuit breaker can temporarily stop calls and fail fast.

Imagine an Order Service calling a Payment Service. The Payment Service becomes slow or unavailable.

The circuit breaker does not fix the Payment Service. It protects the caller and gives the failing dependency breathing room.

Timeouts and retries are useful, but they do not fully solve the problem.

If the dependency is only briefly flaky, retries may help. But if the dependency is consistently failing, retries can make the situation worse by sending even more traffic to something already overloaded.

Dependency starts failing
        ↓
Timeouts happen
        ↓
Retries increase traffic
        ↓
Dependency gets more overloaded
        ↓
More failures
        ↓
Caller starts failing too

A circuit breaker is usually explained using three states:

This gives the system a controlled way to stop traffic, wait, test recovery, and then return to normal.

A circuit breaker usually wraps a remote call.

if circuit is OPEN:
    fail fast

try:
    call dependency
    record success
catch failure:
    record failure
    maybe open circuit

The important part is that in the open state, the service avoids even making the remote call.

This is a deliberately simplified example. Real systems usually use a library like resilience4j, but the basic idea is easier to understand in plain Java.

import java.time.Duration;
import java.time.Instant;
import java.util.function.Supplier;

public class SimpleCircuitBreaker {
    enum State {
        CLOSED,
        OPEN,
        HALF_OPEN
    }

    private State state = State.CLOSED;
    private int failureCount = 0;
    private final int failureThreshold = 3;
    private final Duration openDuration = Duration.ofSeconds(5);
    private Instant openedAt;

    public String call(Supplier<String> dependencyCall) {
        if (state == State.OPEN) {
            if (Instant.now().isBefore(openedAt.plus(openDuration))) {
                throw new RuntimeException("Circuit is open. Failing fast.");
            }

            state = State.HALF_OPEN;
        }

        try {
            String result = dependencyCall.get();
            recordSuccess();
            return result;
        } catch (RuntimeException ex) {
            recordFailure();
            throw ex;
        }
    }

    private void recordSuccess() {
        failureCount = 0;
        state = State.CLOSED;
    }

    private void recordFailure() {
        failureCount++;

        if (failureCount >= failureThreshold) {
            state = State.OPEN;
            openedAt = Instant.now();
        }
    }
}

This example tracks failures. Once enough failures happen, the breaker opens and future calls fail fast until the wait period expires.

When the circuit is open, your service has a few options:

Suppose the recommendation service is failing on an ecommerce site.

Product Page
    ↓
Recommendation Service fails
    ↓
Circuit breaker opens
    ↓
Hide recommendations
    ↓
Still allow product view and checkout

That is much better than failing the entire product page just because recommendations are unavailable.

Circuit breakers are powerful, but the configuration matters.

Not every error should trip a circuit breaker.

Circuit breakers and retries are often used together, but they must be coordinated.

Safe pattern:
timeout per call
limited retries with backoff
circuit breaker around dependency
fallback or graceful degradation

If the circuit is open, do not keep retrying the same failing call. That defeats the purpose of the circuit breaker.

Circuit breakers are not always necessary.

• Simple local function calls
• Very low-volume internal tools
• Cases where a normal timeout is enough
• Operations where fail-fast behavior is worse than waiting

They are most useful around remote dependencies, especially when failure can spread from one service to another.