Implementing Circuit Breakers with Resilience4j/Polly

Don't Let One Service Kill the Platform

How to implement Circuit Breakers to stop cascading failure.

The 'Christmas Tree' Light Effect

• Old Lights — One bulb goes out, the entire string goes dark.
• Microservices — The 'Recommendation Service' is slow. Now the 'Homepage' is waiting... and crashing.
• Resource Exhaustion — Your healthy services run out of threads waiting for the sick service.

The Circuit Breaker Pattern

Closed, Open, Half-Open.

• Closed (Normal) — Traffic flows freely. Failures are counted.
• Open (Broken) — Error threshold reached (e.g., 50% fail). Traffic is blocked instantly.
• Fast Fail — The caller gets an immediate error instead of waiting 30s for a timeout.

The Recovery: Half-Open

• Testing the Waters — After a cooldown (e.g., 60s), allow 1 request through.
• Success — If it works, close the circuit. Resume normal traffic.
• Failure — If it fails, open the circuit again. Wait longer.

Tools: Resilience4j & Polly

• Java (Resilience4j) — Annotation based. @CircuitBreaker(name = "backendA").
• .NET (Polly) — Fluent API. Policy.Handle<Exception>().CircuitBreaker(...).

Fallback Logic

• Graceful Degradation — If Recommendations are down, show 'Most Popular Items' from a cache.
• User Experience — The user sees a slightly worse page, not a 500 error page.

Summary: Fail Fast

Protect your resources.

It is better to refuse a request instantly than to hang efficiently.

Do your failures cascade or isolate?