Circuit breaker with Resilience4j in Spring Boot

Introduction

A circuit breaker helps your system avoid repeated failures by stopping calls to a failing service temporarily. Resilience4j is a tool that makes adding this protection easy in Spring Boot apps.

When calling an external payment service that might be down sometimes.

When your app depends on a slow database or API that can timeout.

When you want to prevent cascading failures in a microservices setup.

When you want to improve system stability by quickly failing fast on errors.

When you want to monitor and control retries and failures automatically.

Syntax

Spring Boot

1. Add Resilience4j dependency to your Spring Boot project.
2. Configure circuit breaker properties in application.yml or application.properties.
3. Annotate your service method with @CircuitBreaker(name = "serviceName", fallbackMethod = "fallbackMethodName").
4. Implement the fallback method to handle failures gracefully.

The name in @CircuitBreaker links to configuration settings.

The fallbackMethod is called when the circuit is open or an error occurs.

Examples

This example protects the callPaymentService method with a circuit breaker named 'paymentService'.

Spring Boot

@CircuitBreaker(name = "paymentService", fallbackMethod = "paymentFallback")
public String callPaymentService() {
    // call external payment API
}

This fallback method returns a friendly message when the payment service call fails.

Spring Boot

public String paymentFallback(Exception e) {
    return "Payment service is down, please try later.";
}

Example configuration in application.properties to set circuit breaker behavior.

Spring Boot

resilience4j.circuitbreaker.instances.paymentService.registerHealthIndicator=true
resilience4j.circuitbreaker.instances.paymentService.slidingWindowSize=10
resilience4j.circuitbreaker.instances.paymentService.failureRateThreshold=50

Sample Program

This Spring Boot app has a REST endpoint /pay that simulates a payment service. It fails twice and succeeds on the third call. The circuit breaker stops calls when failures are high and uses the fallback method to respond gracefully.

Spring Boot

package com.example.demo;

import io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

@RestController
class PaymentController {

    private int attempt = 0;

    @GetMapping("/pay")
    @CircuitBreaker(name = "paymentService", fallbackMethod = "paymentFallback")
    public String pay() {
        attempt++;
        if (attempt % 3 != 0) {
            throw new RuntimeException("Payment service failure");
        }
        return "Payment successful on attempt " + attempt;
    }

    public String paymentFallback(Exception e) {
        return "Payment service is currently unavailable. Please try again later.";
    }
}

Important Notes

Configure circuit breaker properties carefully to balance between sensitivity and availability.

Fallback methods should be quick and safe to avoid further failures.

Use monitoring tools to track circuit breaker states and metrics.

Summary

Circuit breakers protect your app from repeated failures by stopping calls temporarily.

Resilience4j integrates easily with Spring Boot using annotations and configuration.

Fallback methods provide graceful responses when services fail.

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