Circuit Breaker Pattern: Prevent Cascading Failures in Service Calls

Scenario context

Circuit breakers protect callers from repeatedly hitting a failing dependency. They turn slow failure into fast failure, giving the rest of the system room to recover.

stateDiagram-v2
  [*] --> Closed
  Closed --> Open : failure rate exceeds threshold
  Open --> HalfOpen : wait interval elapses
  HalfOpen --> Closed : all probe calls succeed
  HalfOpen --> Open : any probe call fails
  note right of Closed
    Normal traffic flows
    Records outcomes in window
  end note
  note right of Open
    Fail fast or fallback
    No calls to dependency
  end note
  note right of HalfOpen
    Limited probe calls
    Test dependency recovery
  end note

Observable outcome: 📊 State Machine: CLOSED → OPEN → HALF OPEN This state diagram formalizes the three-state circuit breaker lifecycle as a finite state machine with precisely defined transition triggers.

Stage 4 — Concrete Config Example: Resilience4j Breaker Settings

• This Resilience4j circuit breaker YAML configuration targets a fraudService instance — a natural circuit breaker candidate because fraud detection is a non-critical dependency whose failure should never block the primar…
• The slidingWindowSize , failureRateThreshold , and waitDurationInOpenState fields map directly to the three state transitions shown in the state machine diagram above.
• Read the config top to bottom: the sliding window and failure rate threshold control the Closed-to-Open transition, the wait duration controls the Open-to-HalfOpen transition, and permittedNumberOfCallsInHalfOpenState c…
• Why these fields matter: - minimumNumberOfCalls avoids tripping on tiny sample noise.

resilience4j:
  circuitbreaker:
    instances:
      fraudService:
        slidingWindowType: COUNT_BASED
        slidingWindowSize: 50
        minimumNumberOfCalls: 20
        failureRateThreshold: 50
        slowCallRateThreshold: 60
        slowCallDurationThreshold: 500ms
        waitDurationInOpenState: 30s
        permittedNumberOfCallsInHalfOpenState: 5
        automaticTransitionFromOpenToHalfOpenEnabled: true

Observable outcome: Why these fields matter: - minimumNumberOfCalls avoids tripping on tiny sample noise.

Stage 5 — Spring Boot Implementation: Protecting a Fraud Service Call

• The YAML config above tells Resilience4j when to trip.
• The code below wires what happens when it does.
• The scenario: CheckoutService calls FraudService .
• When the fraud service is slow or erroring, the breaker trips and a fallback returns ALLOW WITH REVIEW — checkout stays operational with an audit log entry rather than surfacing a hard error to the customer.

<dependency>
  <groupId>io.github.resilience4j</groupId>
  <artifactId>resilience4j-spring-boot3</artifactId>
  <version>2.2.0</version>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
  <groupId>io.micrometer</groupId>
  <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

management:
  endpoints:
    web:
      exposure:
        include: health,metrics,circuitbreakers
  health:
    circuitbreakers:
      enabled: true

Observable outcome: When the fraud service is slow or erroring, the breaker trips and a fallback returns ALLOW WITH REVIEW — checkout stays operational with an audit log entry rather than surfacing a hard error to the customer.

Stage 6 — Real-World Applications: What to Instrument and What to Alert On

• What breaks first in production: 1.
• Slow calls that do not count as failures.
• Fallback paths that were never load-tested.
• Alerting that focuses on 5xx only and misses degraded open-state behavior.

Observable outcome: Alerting that focuses on 5xx only and misses degraded open-state behavior.

End-to-end outcome

Use a circuit breaker when dependency failure can consume caller capacity faster than the dependency can recover.

Alternatives considered

Decision Guide for Dependency Protection

If your service cannot explain what users receive when the breaker is open, the design is incomplete.

Failure and degraded modes

When Not to Use Circuit Breakers

• Detection: Breakers are not a substitute for basic dependency hygiene.
• User or operator impact: Breakers are not a substitute for basic dependency hygiene.

Trade-offs & Failure Modes: Pros, Cons, and Alternatives

• Detection: Trade-offs & Failure Modes: Pros, Cons, and Alternatives
• User or operator impact: Trade-offs & Failure Modes: Pros, Cons, and Alternatives