
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Resumen Aprenda a hacer que sus llamadas de microservicio sean resistentes utilizando el patrón Circuit Breaker con   y   — demostración completa, comandos paso a paso, explicaciones clase por clase, ejemplos de resultados, casos de uso del mundo real y consejos de producción. Resilience4j Spring Boot Por qué esto es importante En sistemas distribuidos, un servicio descendente que falla puede extenderse y causar interrupciones generales del sistema. El patrón  : Circuit Breaker 
 
 
 
 
 Detecta una dependencia fallida, Deja de enviarle solicitudes (para evitar desperdiciar recursos), Devuelve una respuesta de reserva elegante, Prueba periódicamente la dependencia y restaura la operación normal cuando está en buen estado. Esto reduce el tiempo de inactividad, protege los pools de hilos, mantiene una experiencia de usuario razonable y previene tormentas de reintentos. Resumen de la demostración (lo que tiene) Una demostración de Maven de dos servicios: 
 
 
 
  (puerto  ) — proveedor REST simple que falla intencionalmente de forma intermitente. hello-service 8081 Punto final GET /api/hello
 
 
 
 
  (puerto  ) — llama a hello-service usando RestTemplate y está protegido por   con un fallback. client-service 8080 Resilience4j @CircuitBreaker Punto final GET /api/get-message
 Ejecute ambos ( ) hello-service y client-service Luego pruebe GET http://localhost:8080/api/get-message
 Diagrama de Arquitectura Este es un flujo pequeño y enfocado adecuado para dibujar un diagrama Archivos y Código: Explicación Clase por Clase hello-service HelloServiceApplication.java 
 
 
 
 Clase de arranque estándar  . @SpringBootApplication HelloController.java

@RestController
public class HelloController {

    private static int counter = 0;

    @GetMapping("/api/hello")
    public String sayHello() {
        counter++;
        // simular falla intermitente: fallar en cada 3ª solicitud
        if (counter % 3 == 0) {
            throw new RuntimeException("Simulated failure from Hello-Service!");
        }
        return "Hello from Hello-Service! (count=" + counter + ")";
    }
}
  Este controlador lanza intencionalmente una RuntimeException en llamadas periódicas para simular fallas transitorias que vería en sistemas reales (interrupción de DB, datos incorrectos, tiempos de espera agotados). Explicación: client-service ClientServiceApplication.java 
 
 Clase principal estándar de Spring Boot. No se requiere configuración especial. AppConfig.java
@Configuration
public class AppConfig {
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}
  Proporciona un único bean RestTemplate. Asegúrese de que RestTemplate sea un bean de Spring para que los proxies AOP/resiliencia funcionen correctamente. Explicación: HelloClientService.java
@Service
public class HelloClientService {

    private final RestTemplate restTemplate;

    @Value("${hello.service.url}")
    private String helloServiceUrl;

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

    @CircuitBreaker(name = "helloService", fallbackMethod = "fallbackHello")
    public String getHelloMessage() {
        System.out.println("Calling hello service: " + helloServiceUrl);
        return restTemplate.getForObject(helloServiceUrl, String.class);
    }

    public String fallbackHello(Throwable t) {
        System.out.println("Fallback triggered: " + t);
        return "Hello Service is currently unavailable. Please try again later.";
    }
}
 Explicación (partes cruciales) 
 
 
 
 
 
 @CircuitBreaker(name = "helloService", fallbackMethod = "fallbackHello") envuelve la llamada getHelloMessage() en un circuit breaker. El nombre se vincula a las propiedades de configuración. 
 
 
 
 fallbackHello(Throwable t) se llama cuando la llamada falla según las reglas del breaker.  El fallback debe:     o    Estar en la misma clase

    o    Tener el mismo tipo de retorno

    o   Aceptar los parámetros del método original (ninguno aquí) y un parámetro Throwable final (o Exception/Throwable compatible con las excepciones lanzadas)
 
 
 Importante: El método debe ser público y la clase debe ser un bean de Spring (@Service), para que el AOP basado en proxy funcione. ClientController.java
@RestController
public class ClientController {

    private final HelloClientService helloClientService;

    public ClientController(HelloClientService helloClientService) {
        this.helloClientService = helloClientService;
    }

    @GetMapping("/api/get-message")
    public String getMessage() {
        return helloClientService.getHelloMessage();
    }
}
  Controlador simple que delega a  . Esto asegura que la llamada pase por el proxy donde se aplica el circuit breaker. Explicación: HelloClientService Configuración utilizada (client-service application.properties) Configuración clave utilizada en la demostración server.port=8080
spring.application.name=client-service

hello.service.url=http://localhost:8081/api/hello

resilience4j.circuitbreaker.instances.helloService.registerHealthIndicator=true
resilience4j.circuitbreaker.instances.helloService.slidingWindowSize=5
resilience4j.circuitbreaker.instances.helloService.minimumNumberOfCalls=2
resilience4j.circuitbreaker.instances.helloService.failureRateThreshold=50
resilience4j.circuitbreaker.instances.helloService.waitDurationInOpenState=10s

logging.level.io.github.resilience4j.circuitbreaker=DEBUG
 Significado de las propiedades importantes 
 
 
 
 
 
  número de llamadas que el breaker monitorea para el porcentaje de fallos. slidingWindowSize:  número mínimo de llamadas antes de que se evalúe la tasa de fallos. minimumNumberOfCalls:  porcentaje de fallos (por ejemplo, 50) para abrir el circuito. failureRateThreshold:  cuánto tiempo permanece abierto el circuito antes de pasar a medio abierto. waitDurationInOpenState:  expone el estado del breaker a través del actuator. registerHealthIndicator: Ejecución Paso a Paso y Resultados Esperados Inicio de Servicios 
 
 Inicio de  hello-service Visita: http://localhost:8081/api/hello
  → "Hello from Hello-Service!" (o lanza un fallo simulado) Devuelve 
 
 Inicio de  client-service Visita: http://localhost:8080/api/get-message
 Escenarios de Prueba y Resultados Escenario A — hello-service Sano Realizar una solicitud GET http://localhost:8080/api/get-message
 Registros del cliente Calling hello service: http://localhost:8081/api/hello
2025-11-13T11:58:23.366+05:30 DEBUG 32692 --- [client-service] [nio-8080-exec-8] i.g.r.c.i.CircuitBreakerStateMachine : CircuitBreaker 'helloService' succeeded:
2025-11-13T11:58:23.366+05:30 DEBUG 32692 --- [client-service] [nio-8080-exec-8] i.g.r.c.i.CircuitBreakerStateMachine : Event SUCCESS published: 2025-11-13T11:58:23.366634+05:30[Asia/Calcutta]: CircuitBreaker 'helloService' recorded a successful call. Elapsed time: 15 ms
 Respuesta Hello from Hello-Service! (count=4)
 Escenario B — Fallos Intermitentes de hello-service Si llama repetidamente y hello-service lanza   en algunas solicitudes: RuntimeException ● Llamadas exitosas: el cliente devuelve el mensaje de saludo. ●  Cuando una llamada descendente devuelve HTTP 500/excepción:             o    Resilience4j registra el fallo.

            o    Si la tasa de fallos supera el umbral (por ejemplo, 50% en la ventana deslizante), el Circuito se vuelve **ABIERTO**.

            o    Mientras está ABIERTO, las llamadas se cortocircuitan; se ejecuta inmediatamente **fallbackHello**() — no hay llamada de red. \n                       **Respuesta del cliente mientras el fallback está activo**
 Respuesta del cliente mientras está activo Respuesta Hello Service is currently unavailable. Please try again later.
 Secuencia de registro de cliente de ejemplo Calling hello service: http://localhost:8081/api/hello
2025-11-13T12:00:55.842+05:30 DEBUG 32692 --- [client-service] [nio-8080-exec-1] i.g.r.c.i.CircuitBreakerStateMachine : CircuitBreaker 'helloService' recorded an exception as failure:
 Escenario C — Recuperación Después de    waitDurationInOpenState (10s): 
 
 
 
 El circuito pasa a  : se permiten algunas llamadas de prueba. HALF_OPEN Si las llamadas de prueba tienen éxito, el breaker se   y se reanuda el tráfico normal. CIERRA Si las pruebas fallan, el breaker vuelve a  . OPEN Casos de Uso del Mundo Real 
 
 
 
 
  Un servicio de pago que llama a una API bancaria externa: si la API del banco se vuelve lenta/falla, el circuit breaker devuelve un mensaje fácil de usar y previene tormentas de reintentos. Integración de Pagos -  APIs con llamadas limitadas por segundo — cuando se alcanzan los límites, el circuito se abre para evitar golpear más cuotas; el fallback devuelve datos en caché. APIs de terceros con límite de tasa -  El servicio A llama al B, que llama al C. Si C es inestable, los breakers abiertos protegen B y A, previniendo la ralentización de todo el sistema. Cadenas de microservicios dentro de una empresa -  Cuando falla un servicio de función no crítica, devuelve un resultado más simple para mantener la funcionalidad principal disponible (por ejemplo, devolver la lista de productos sin recomendaciones). Interruptores de funciones y degradación elegante - Ventajas y Valor Empresarial 
 
 
 
 
 
 
  — evita que una dependencia defectuosa se propague. Aislamiento de fallos  — falla rápidamente en lugar de esperar tiempos de espera agotados. Respuesta de fallo más rápida  — ofrece respuestas de fallback en lugar de interrupciones completas. Degradación elegante  — evita desperdiciar CPU, hilos y red. Protección de recursos  — vuelve automáticamente a la normalidad cuando la dependencia está en buen estado. Recuperación automática  — los estados y métricas del breaker se pueden exponer a través del Actuator y monitorearse. Observabilidad Registros de ejemplo que verá (realistas) Calling hello service: http://localhost:8081/api/hello
2025-11-13T12:00:55.842+05:30 DEBUG 32692 --- [client-service] [nio-8080-exec-1] i.g.r.c.i.CircuitBreakerStateMachine : CircuitBreaker 'helloService' recorded an exception as failure
2025-11-13T12:00:55.847+05:30 DEBUG 32692 --- [client-service] [nio-8080-exec-1] i.g.r.c.i.CircuitBreakerStateMachine : Event ERROR published: 2025-11-13T12:00:55.847908200+05:30[Asia/Calcutta]: CircuitBreaker 'helloService' recorded an error: 'org.springframework.web.client.HttpServerErrorException$InternalServerError: 500 : "{"timestamp":"2025-11-13T06:30:55.842+00:00","status":500,"error":"Internal Server Error","path":"/api/hello"}"'. Elapsed time: 8 ms
Fallback triggered: org.springframework.web.client.HttpServerErrorException$InternalServerError: 500 : "{"timestamp":"2025-11-13T06:30:55.842+00:00","status":500,"error":"Internal Server Error","path":"/api/hello"}"


Read My Stories

Este audio es producido en el idioma original de la historia!

Cómo crear APIs resilientes con Resilience4j Circuit Breaker en Spring Boot

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps