# Qué es un circuit breaker en microservicios y cómo funciona > Un circuit breaker corta temporalmente las llamadas a un servicio que falla para que el resto del sistema pueda seguir funcionando. Esta guía explica sus estados, qué medir, cuándo reintentar y cómo probar la recuperación sin ocultar el problema. - URL canónica: https://visteesto.com/nota/circuit-breaker-microservicios-que-es - Autor: [Martin Rodriguez](https://visteesto.com/autor/martin-rodriguez) - Publicado: 2026-09-29T09:00:00.000Z - Actualizado: 2026-09-29T09:00:00.000Z - Sección: Tecnología - Tema: circuit-breaker-microservicios - Idioma: es - Consulta principal: qué es un circuit breaker en microservicios ## Resumen verificable - El patrón corta llamadas a una dependencia que falla para limitar una cascada de errores. ([evidencia](https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker)) - El circuito usa estados cerrado, abierto y medio abierto para decidir cuándo enviar y cuándo probar llamadas. ([evidencia](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/circuit-breaker.html)) - Timeouts y reintentos deben combinarse con pausas y límites para no multiplicar la carga durante una falla. ([evidencia](https://martinfowler.com/bliki/CircuitBreaker.html)) - Una implementación debe medir transiciones, llamadas rechazadas y recuperación para ajustar sus umbrales. ([evidencia](https://resilience4j.readme.io/docs/circuitbreaker)) ## Aporte editorial de VisteEsto VisteEsto convierte el patrón en una secuencia operativa: definir la falla, separar estados, combinar timeout y backoff, elegir una respuesta alternativa y probar la recuperación con métricas que expliquen cada transición. ## Qué problema resuelve un circuit breaker En un sistema distribuido, una llamada a otro servicio puede tardar, devolver errores o quedar bloqueada. Si cada instancia sigue esperando y reintentando, consume conexiones y hilos que también necesita el resto de la aplicación. El fallo inicial termina convertido en una cascada de demoras. El circuit breaker agrega una decisión entre el consumidor y el servicio remoto. Cuando detecta demasiados fallos o tiempos de espera, deja de enviar llamadas durante un intervalo. La aplicación recibe una respuesta alternativa, un error rápido o una cola, según lo que tenga sentido para esa operación. El patrón no arregla el servicio que falló ni garantiza que la respuesta alternativa sea correcta. Su objetivo es limitar el radio de impacto y dejar una señal visible para que el equipo investigue. Microsoft y AWS lo describen como una forma de evitar que un problema remoto se propague al consumidor. ## Los tres estados del patrón En estado cerrado, las llamadas pasan normalmente y el componente registra éxitos, errores y tiempos de respuesta. Una política define qué cuenta como fallo: un código HTTP, una excepción, un timeout o una combinación. El umbral debe reflejar la operación, porque no todos los errores tienen la misma gravedad. Cuando la tasa de fallos supera ese umbral, el circuito pasa a abierto. Las llamadas se rechazan sin contactar al servicio remoto hasta que termina el tiempo de espera configurado. Ese corte rápido protege recursos, pero la aplicación debe diferenciarlo de una respuesta válida y registrar el motivo. Después de la pausa, el estado medio abierto permite probar con pocas llamadas. Si esas pruebas tienen éxito, el circuito vuelve a cerrado; si fallan, regresa a abierto y espera otro intervalo. El tamaño de la muestra y el tiempo de pausa deben evitar tanto la recuperación prematura como la espera innecesaria. ## Timeouts, reintentos y respuestas alternativas Un circuito no puede decidir bien si la llamada no tiene un timeout explícito. Una espera infinita ocupa recursos y retrasa la detección del fallo. El límite debe ser menor que el tiempo total que el usuario o el proceso puede tolerar, y debe incluir el tiempo de conexión y el de lectura. Los reintentos se combinan con cuidado. Repetir una operación de lectura puede ayudar ante una falla transitoria, pero hacerlo junto con varios clientes puede generar una tormenta cuando el servicio vuelve. Un backoff con jitter, un máximo pequeño y un circuito que corte pronto reducen esa presión. La respuesta alternativa depende de la operación. Puede ser un dato en caché con su fecha, una cola para procesar después o un mensaje que indique que el resultado no está disponible. No conviene devolver datos viejos como si fueran actuales: la alternativa debe declarar sus límites y mantener la trazabilidad de la falla original. ## Qué observar antes de ajustar el umbral Registrá cada transición de estado con el nombre del servicio, la operación, la causa y la duración. En métricas separadas conviene observar tasa de errores, timeouts, llamadas rechazadas por el circuito, latencia de las pruebas y tiempo que permanece abierto. Un promedio general puede esconder un endpoint que falla de manera aislada. Las alertas deben distinguir una dependencia caída de un circuito mal configurado. Si casi todas las pruebas pasan pero el estado sigue abierto, el umbral o la ventana pueden ser demasiado agresivos. Si el servicio se recupera y vuelve a caer apenas se cierra, la prueba permite detectar que la recuperación no es estable. El patrón también necesita un identificador de recorrido para relacionar la llamada original, los reintentos y la respuesta alternativa. Esa correlación evita contar un mismo incidente varias veces y permite comprobar si la protección redujo la carga. Los logs no deben incluir secretos ni datos personales sólo porque una llamada falló. ## Checklist para implementar un circuit breaker Definí primero la operación protegida y su comportamiento aceptable: timeout, códigos que indican fallo, cantidad de errores y ventana de observación. Elegí por separado el tiempo abierto, la cantidad de pruebas en medio abierto y la respuesta alternativa. Documentar esas decisiones evita copiar valores de otra dependencia. Probá una caída completa, timeouts lentos, errores intermitentes y una recuperación parcial. Verificá que el consumidor deje de llamar cuando corresponde, que no multiplique reintentos y que vuelva a probar después de la pausa. Medí también qué ocurre cuando varios procesos abren el circuito al mismo tiempo. Por último, comprobá la operación con el circuito abierto: la alerta debe llegar, la métrica debe conservar el contexto y el equipo debe poder cambiar la configuración sin redeployar toda la aplicación. Un circuit breaker bien implementado hace visible un fallo y limita su alcance; no debe convertirse en una forma silenciosa de esconderlo. ## Fuentes consultadas - Fuente primaria: [Microsoft Azure Architecture Center: Circuit Breaker pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker) - Fuente primaria: [AWS Prescriptive Guidance: Circuit breaker pattern](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/circuit-breaker.html) - Fuente secundaria: [Martin Fowler: CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html) - Fuente secundaria: [Resilience4j: CircuitBreaker](https://resilience4j.readme.io/docs/circuitbreaker) ## Imágenes y licencias - Circuito que corta llamadas entre microservicios cuando una dependencia falla. Autor: VisteEsto. Licencia: [VisteEsto editorial](https://visteesto.com/terminos). [Origen](https://visteesto.com/nota/circuit-breaker-microservicios-que-es). - Estados cerrado abierto y medio abierto de un circuit breaker. Autor: VisteEsto. Licencia: [VisteEsto editorial](https://visteesto.com/terminos). [Origen](https://visteesto.com/nota/circuit-breaker-microservicios-que-es). - Métricas que muestran llamadas rechazadas y recuperación de un servicio. Autor: VisteEsto. Licencia: [VisteEsto editorial](https://visteesto.com/terminos). [Origen](https://visteesto.com/nota/circuit-breaker-microservicios-que-es). ## Cómo citar Citar título, autor, fecha de publicación o actualización y la URL canónica. Las afirmaciones centrales incluyen su evidencia directa arriba. Esta versión Markdown es una representación accesible; la nota HTML canónica es la fuente editorial de referencia.