Provides fault tolerance patterns for Spring Boot 3.x using Resilience4j. Use when implementing circuit breakers, handling service failures, adding retry logic with exponential backoff, configuring rate limiters, or protecting services from cascading failures. Generates circuit breaker, retry, rate

Spring Boot Resilience4j Patterns Overview Provides Resilience4j patterns (circuit breaker, retry, rate limiter, bulkhead, time limiter, fallback) for Spring Boot 3.x fault tolerance with configuration and testing workflows. When to Use Implementing fault tolerance and preventing cascading failures Adding circuit breakers, retry logic, or rate limiting to service calls Handling transient failures with exponential backoff Protecting services from overload and resource exhaustion Combining multiple patterns for comprehensive resilience Instructions 1. Setup and Dependencies Add Resilience4j dependencies to your project. For Maven, add to pom.xml : For Gradle, add to build.gradle : Enable AOP annotation processing with @EnableAspectJAutoProxy (auto configured by Spring Boot). 2. Circuit Breaker Pattern Apply @CircuitBreaker annotation to methods calling external services: Configure in application.yml : See @references/configuration reference.md for complete circuit breaker configuration options. 3. Retry Pattern Apply @Retry annotation for transient failure recovery: Configure retry in application.yml : See @references/configuration reference.md for retry exception configuration. 4. Rate Limiter Pattern Apply @RateLimiter to control request rates: Configure in application.yml : 5. Bulkhead Pattern Apply @Bulkhead to isolate resources. Use type = SEMAPHORE for synchronous methods: Use type = THREADPOOL for async/CompletableFuture methods: Configure in application.yml : 6. Time Limiter Pattern Apply @TimeLimiter to async methods to enforce timeout boundaries: Configure in application.yml : 7. Combining Multiple Patterns Stack multiple patterns on a single method for comprehensive fault tolerance: Execution order: Retry → CircuitBreaker → RateLimiter → Bulkhead → Method All patterns should reference the same named configuration instance for consistency. 8. Exception Handling and Monitoring Create a global exception handler using @RestControllerAdvice : Enable Actuator endpoints for monitoring resilience patterns in application.yml : Access monitoring endpoints: GET /actuator/health Overall health including resilience patterns GET /actuator/circuitbreakers Circuit breaker states GET /actuator/metrics Custom resilience metrics Testing & Verification Workflow 1. Circuit Breaker : Call endpoint with failures → check GET /actuator/circuitbreakers shows OPEN → wait waitDurationInOpenState → verify state transitions to HALF OPEN → CLOSED 2. Retry : Enable resilience4j.retry.metrics.enabled: true → invoke endpoint → verify retry.{instance}.successful calls with retry attempts metric increases 3. Rate Limiter : Send requests exceeding limitForPeriod → verify 429 status → check GET /actuator/ratelimiters shows LIMITED 4. Bulkhead : Load test with concurrent requests exceeding maxConcurrentCalls → verify excess requests fail immediately with BulkheadFullException 5. Time Limiter : Mock async delay beyond timeoutDuration → verify fallback triggers after timeout See @references/testing patterns.md for unit and integration testing strategies. Best Practices Provide fallback methods : Ensure graceful degradation with meaningful responses Use exponential backoff : Prevent overwhelming recovering services ( exponentialBackoffMultiplier: 2 ) Set appropriate thresholds : failureRateThreshold between 50 70% Use constructor injection : Never use field injection for Resilience4j dependencies Enable health indicators : Set registerHealthIndicator: true for all patterns Retry only transient errors : Network timeouts, 5xx; skip 4xx and business exceptions Size bulkheads based on load : Calculate thread pool and semaphore sizes from expected concurrency Document fallback behavior : Make fallback logic clear and predictable Constraints and Warnings Fallback methods must have the same signature plus an optional exception parameter Circuit breaker state is per instance; ensure proper bean scoping in multi tenant scenarios Retry operations must be idempotent (may execute multiple times) Do not use circuit breakers for operations that must always complete; use timeouts instead Rate limiters can cause thread blocking; configure appropriate wait durations Be cautious with @Retry on non idempotent operations like POST requests Monitor memory when using thread pool bulkheads with high concurrency Examples Before → After: Circuit Breaker Before → After: Retry with Backoff Before → After: Rate Limiting See also: [Configuration Reference](references/configuration reference.md) · [Testing Patterns](references/testing patterns.md) · [Examples](references/examples.md) · [Resilience4j Docs](https://resilience4j.readme.io/) · [Actuator Skill](../spring boot actuator/SKILL.md)

spring-boot-resilience4j