Circuit breaker with Resilience4j in Spring Boot - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the primary purpose of a circuit breaker in microservices?

Select the main reason why a circuit breaker pattern is used in microservices architecture.

A To cache responses from a service to improve performance

B To encrypt communication between microservices for security

C To balance load evenly across multiple instances of a service

D To prevent a service from repeatedly calling a failing downstream service and allow it to recover

💡 Hint

Think about how to avoid cascading failures when a service is down.

The circuit breaker stops calls to a failing service temporarily, allowing it to recover and preventing cascading failures.

❓ Architecture

intermediate

Which component in Resilience4j handles the state transitions of a circuit breaker?

Identify the Resilience4j component responsible for managing the states (closed, open, half-open) of a circuit breaker.

A CircuitBreaker

B Bulkhead

C CircuitBreakerRegistry

D Retry

💡 Hint

This component directly wraps the protected function and tracks failures.

The CircuitBreaker interface manages the state transitions and decides whether to allow calls or not.

❓ scaling

advanced

How does Resilience4j's circuit breaker behave under high concurrent load when many calls fail?

Consider a scenario where many concurrent requests to a downstream service fail. What will the circuit breaker do to handle this load?

A It scales the number of circuit breakers dynamically based on load

B It immediately opens the circuit after the failure threshold is reached, blocking further calls until reset

C It ignores failures under high load to maintain throughput

D It queues all requests and retries them sequentially to avoid overload

💡 Hint

Think about how the circuit breaker protects the system from overload.

When failure rate exceeds the threshold, the circuit breaker opens to block calls, preventing overload and allowing recovery.

❓ tradeoff

advanced

What is a tradeoff when setting a very low failure rate threshold in Resilience4j circuit breaker?

If you configure the circuit breaker with a very low failure rate threshold (e.g., 1%), what is a likely tradeoff?

A The circuit breaker may open too frequently, causing unnecessary blocking of calls

B The circuit breaker will never open, ignoring real failures

C The circuit breaker will consume excessive memory resources

D The circuit breaker will cause increased network latency

💡 Hint

Think about sensitivity to failures and how it affects call blocking.

A very low failure threshold causes the circuit breaker to open often, even for minor or transient failures, which can reduce availability.

❓ component

expert

In a Spring Boot application using Resilience4j, which annotation enables declarative circuit breaker support?

Choose the correct annotation to apply on a method to enable circuit breaker functionality with Resilience4j in Spring Boot.

A @EnableCircuitBreaker

B @Resilience4jCircuitBreaker

C @CircuitBreaker(name = "backendService")

D @CircuitBreakerEnabled

💡 Hint

Look for the annotation that specifies the circuit breaker name directly on the method.

The @CircuitBreaker annotation from Resilience4j is used on methods to enable circuit breaker behavior declaratively.

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