Circuit breakers with Resilience4j

A circuit breaker watches calls to a dependency and, after enough failures, fails fast for a while instead of waiting on a dead service. It protects your threads and gives the dependency room to recover.

What a session covers

The tutor works through these with you, in conversation and code. A session ends when you have shown them, not when a video does.

Explain the closed, open and half-open states
Wrap a remote call in a circuit breaker and configure its thresholds
Spot the fallback that hides the failure as a real answer

In practice

A few lines that show Circuit breakers with Resilience4j doing its job.

Java

@Service
class PricingClient {
    @CircuitBreaker(name = "catalog", fallbackMethod = "cachedPrice")
    Price priceOf(String sku) { return client.get().uri("/prices/{sku}", sku).retrieve().body(Price.class); }

    Price cachedPrice(String sku, Throwable cause) { return cache.getOrDefault(sku, Price.UNKNOWN); }
}

// application.yml
// resilience4j.circuitbreaker.instances.catalog:
//   sliding-window-size: 20
//   failure-rate-threshold: 50
//   wait-duration-in-open-state: 30s

The common mistake

Watch for

A fallback that hides the failure completely, returning an empty list as if it were the real answer. Callers then make decisions on missing data; make the fallback visible or degrade explicitly.

What to know first

Your roadmap puts these before Circuit breakers with Resilience4j, unless you already know them.

Service boundaries

How it stays learned

Once a session shows you understand Circuit breakers with Resilience4j, it comes back for review. Each review takes a minute and tells the memory model how well you still know it.

Day 3First recall, while it is fresh
Day 7Second, a week on
Day 18Last, when it has settled

Next in the moduleRetries and timeouts →