Circuit breaker with Resilience4j in Spring Boot - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the main purpose of a circuit breaker in system design?

A circuit breaker helps prevent a system from repeatedly trying to perform an operation that is likely to fail, protecting resources and allowing the system to recover gracefully.

intermediate

How does Resilience4j implement the circuit breaker pattern?

Resilience4j provides a lightweight, easy-to-use circuit breaker that monitors failures and controls calls to external services by opening, closing, or half-opening the circuit based on failure rates and timeouts.

beginner

What are the three states of a circuit breaker in Resilience4j?

Closed (normal operation), Open (calls are blocked), and Half-Open (test calls allowed to check if service has recovered).

intermediate

In Resilience4j, what happens when the failure rate exceeds the threshold configured in the circuit breaker?

The circuit breaker transitions from Closed to Open state, blocking further calls to the failing service for a configured wait duration.

intermediate

Why is the Half-Open state important in a circuit breaker?

It allows the system to test if the external service has recovered by allowing a limited number of calls before fully closing the circuit again.

What state does a circuit breaker enter when it detects too many failures?

A Open

B Closed

C Half-Open

D Disabled

When failures exceed the threshold, the circuit breaker opens to stop calls to the failing service.

Which Resilience4j feature allows you to automatically retry calls after a failure?

A Circuit Breaker

B Rate Limiter

C Bulkhead

D Retry

The Retry feature in Resilience4j automatically retries failed calls based on configuration.

In Resilience4j, what does the Half-Open state do?

A Blocks all calls

B Allows limited test calls

C Allows all calls

D Disables the circuit breaker

Half-Open state allows a limited number of calls to test if the service has recovered.

Which metric does Resilience4j use to decide when to open the circuit breaker?

A Failure rate

B CPU usage

C Memory usage

D Response time

Resilience4j opens the circuit breaker when the failure rate exceeds a configured threshold.

What is the benefit of using a circuit breaker in microservices?

A Improves UI responsiveness

B Speeds up network traffic

C Prevents cascading failures

D Increases database size

Circuit breakers prevent cascading failures by stopping calls to failing services.

Explain how a circuit breaker works in Resilience4j and why it is useful in a microservices architecture.

Think about how it protects your system from repeated failures.

Describe the configuration options you can set for a Resilience4j circuit breaker and their impact on system behavior.

Consider how these settings control when and how the circuit breaker opens or closes.

Practice

1. What is the primary purpose of using a circuit breaker like Resilience4j in a Spring Boot application?

easy

A. To automatically scale the application horizontally

B. To increase the speed of database queries

C. To encrypt data sent between microservices

D. To prevent repeated calls to a failing service and allow recovery

Solution

1. Step 1: Understand circuit breaker role

   A circuit breaker stops calls to a failing service temporarily to avoid cascading failures.

2. Step 2: Identify the main benefit

   This helps the system recover and prevents wasting resources on repeated failing calls.

3. Final Answer:

   To prevent repeated calls to a failing service and allow recovery -> Option D

4. Quick Check:

   Circuit breaker purpose = prevent repeated failures [OK]

Hint: Circuit breaker stops repeated failing calls [OK]

Common Mistakes:

• Confusing circuit breaker with scaling
• Thinking it speeds up database queries
• Assuming it encrypts data

2. Which annotation is used in Spring Boot to apply a Resilience4j circuit breaker on a method?

easy

A. @Transactional

B. @CircuitBreaker

C. @Cacheable

D. @Retryable

Solution

1. Step 1: Recall Resilience4j integration

   Resilience4j provides the @CircuitBreaker annotation to mark methods for circuit breaking.

2. Step 2: Differentiate from other annotations

   @Retryable is for retries, @Cacheable for caching, and @Transactional for DB transactions.

3. Final Answer:

   @CircuitBreaker -> Option B

4. Quick Check:

   Resilience4j circuit breaker annotation = @CircuitBreaker [OK]

Hint: Use @CircuitBreaker to enable circuit breaking [OK]

Common Mistakes:

• Confusing with @Retryable for retries
• Using caching or transaction annotations incorrectly
• Misspelling annotation names

3. Given this Spring Boot method with Resilience4j circuit breaker:

@CircuitBreaker(name = "serviceA", fallbackMethod = "fallback")
public String callService() {
    // calls external service
    throw new RuntimeException("Service down");
}

public String fallback(Throwable t) {
    return "Fallback response";
}

What will be the output when callService() is invoked?

medium

A. "Fallback response"

B. RuntimeException thrown

C. null

D. Method callService() returns normally

Solution

1. Step 1: Analyze method behavior with circuit breaker

   The method throws an exception, but the circuit breaker calls the fallback method.

2. Step 2: Understand fallback method output

   The fallback method returns the string "Fallback response" which is returned to the caller.

3. Final Answer:

   "Fallback response" -> Option A

4. Quick Check:

   Fallback method output = "Fallback response" [OK]

Hint: Exception triggers fallback method output [OK]

Common Mistakes:

• Expecting exception to propagate without fallback
• Assuming null is returned on failure
• Thinking method returns normally without fallback

4. Consider this incorrect Resilience4j usage in Spring Boot:

@CircuitBreaker(name = "serviceB", fallback = "fallbackMethod")
public String fetchData() {
    // call external API
}

What is the main issue with this code?

medium

A. The method fetchData must return void

B. Circuit breaker name cannot be "serviceB"

C. The fallback method name should be specified with fallbackMethod, not fallback

D. The annotation @CircuitBreaker cannot be used on public methods

Solution

1. Step 1: Check annotation attribute names

   The correct attribute for fallback method name is fallbackMethod, not fallback.

2. Step 2: Validate other conditions

   Method return type and visibility are valid; circuit breaker name can be any string.

3. Final Answer:

   The fallback method name should be specified with fallbackMethod, not fallback -> Option C

4. Quick Check:

   Correct fallback attribute = fallbackMethod [OK]

Hint: Use fallbackMethod attribute for fallback name [OK]

Common Mistakes:

• Using 'fallback' instead of 'fallbackMethod'
• Thinking method must be void
• Assuming circuit breaker name is restricted

5. You want to design a Spring Boot microservice that calls an unstable external payment API. Using Resilience4j circuit breaker, which approach best ensures system stability and graceful degradation?

hard

A. Apply @CircuitBreaker with a fallback method returning a cached payment status

B. Remove circuit breaker and rely on retries only

C. Use @CircuitBreaker without fallback to fail fast

D. Disable circuit breaker and increase thread pool size

Solution

1. Step 1: Understand system stability needs

   Using a circuit breaker prevents repeated calls to the unstable API, avoiding overload.

2. Step 2: Importance of fallback for graceful degradation

   A fallback method returning cached or default data keeps the system responsive during failures.

3. Step 3: Evaluate other options

   Retries alone can worsen overload; no fallback causes failures; increasing threads doesn't solve API instability.

4. Final Answer:

   Apply @CircuitBreaker with a fallback method returning a cached payment status -> Option A

5. Quick Check:

   Circuit breaker + fallback = stability + graceful degradation [OK]

Hint: Combine circuit breaker with fallback for best resilience [OK]

Common Mistakes:

• Relying only on retries without circuit breaker
• Not providing fallback causing failures
• Increasing threads without handling failures