Circuit Breaker Pattern with Resilience4j

The circuit breaker pattern prevents cascading failures in synchronous microservice chains. When a downstream service degrades, the circuit breaker detects the pattern and starts failing fast — protecting the caller from exhausting its thread pool waiting for responses that won't arrive in time.

How Resilience4j's three-state machine works:

• CLOSED is normal — calls go through and failure metrics are recorded against a sliding window of the last N calls
• When failure rate exceeds the threshold (typically 50%), it transitions to OPEN — every call returns immediately with the fallback response, no downstream attempt is made
• After a wait duration (10–30 seconds), it moves to HALF_OPEN and lets a few probe calls through; success closes the breaker, failure reopens it

Critical configuration decisions:

• The recordExceptions filter is what most people miss — business validation errors like "invalid product ID" should NOT count as infrastructure failures and trip the breaker; only timeouts, connection refused, and 5xx should
• slowCallDurationThreshold catches degradation before hard failures appear — a service responding in 5 seconds ties up threads just as badly as a timeout; set it to 2–3× your expected p99 latency

Composing with other patterns:

• Always pair circuit breakers with bulkheads — separate thread pools per dependency so a failing inventory service can't exhaust the pool that payments and shipping also use
• Compose with retry as the outer decorator so the circuit breaker sees the aggregate outcome, not each individual retry attempt

I recommend alerting on state transitions (CLOSED→OPEN) rather than failure rates — a transition means users are getting degraded responses, which is a production incident.