Circuit breaker with Resilience4j in Spring Boot - Mini Project: Build & Apply

Circuit breaker with Resilience4j

📖 Scenario: You are building a Spring Boot microservice that calls an external payment API. The payment API occasionally goes down, and you want to prevent cascading failures by adding a circuit breaker using Resilience4j.

🎯 Goal: Add Resilience4j circuit breaker to a Spring Boot service method with a fallback that returns a safe default response when the payment API is unavailable.

📋 What You'll Learn

Add the Resilience4j Spring Boot starter dependency

Configure circuit breaker properties in application.yml

Create a service method annotated with @CircuitBreaker

Implement a fallback method that returns a default response

💡 Why This Matters

🌍 Real World

Circuit breakers are essential in microservice architectures where services depend on external APIs that can fail. They prevent cascading failures and keep applications responsive.

💼 Career

Understanding resilience patterns like circuit breakers is critical for backend developers building production microservices in Spring Boot.

1

Add Resilience4j dependency

Add the Resilience4j Spring Boot starter dependency to your pom.xml file inside the <dependencies> section.

Spring Boot

    
        org.springframework.boot
        spring-boot-starter-web
    
    
    

Hint

The group ID is io.github.resilience4j and the artifact ID is resilience4j-spring-boot3.

2

Configure circuit breaker in application.yml

Add circuit breaker configuration in application.yml. Set the sliding window size to 10 calls, failure rate threshold to 50 percent, and wait duration in open state to 30 seconds.

Spring Boot

# application.yml
resilience4j:
  circuitbreaker:
    instances:
      paymentService:
        # Configure sliding window size, failure threshold, and wait duration
        # Your code here

Hint

Use slidingWindowSize, failureRateThreshold, and waitDurationInOpenState under the named instance.

3

Create service method with @CircuitBreaker

Create a PaymentService class with a method processPayment annotated with @CircuitBreaker. Set the circuit breaker name to paymentService and the fallback method to paymentFallback. The method should use RestTemplate to call the payment API.

Spring Boot

import io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker;
import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;

@Service
public class PaymentService {

    private final RestTemplate restTemplate;

    public PaymentService(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    // Add @CircuitBreaker annotation with name and fallbackMethod
    // Call payment API using restTemplate
    // Your code here
}

Hint

Use @CircuitBreaker(name = "paymentService", fallbackMethod = "paymentFallback") above your method.

4

Implement fallback method

Add a fallback method called paymentFallback in the same class. It must have the same parameters as processPayment plus a Throwable parameter. Return a default response string indicating the payment is queued for retry.

Spring Boot

import io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker;
import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;

@Service
public class PaymentService {

    private final RestTemplate restTemplate;

    public PaymentService(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    @CircuitBreaker(name = "paymentService", fallbackMethod = "paymentFallback")
    public String processPayment(String orderId) {
        return restTemplate.getForObject(
            "http://payment-service/api/pay/" + orderId, String.class);
    }

    // Create paymentFallback with same params + Throwable
    // Return a default response
    // Your code here
}

Hint

The fallback method must match the return type and parameters of the original method, with an additional Throwable parameter at the end.

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