Explica el patrón circuit breaker y dime cuándo hace más daño que bien.

Un circuit breaker registra los fallos hacia una dependencia, se abre cuando se cruza un umbral para que las llamadas fallen rápido en lugar de acumularse, y luego pasa a semiabierto para probar la recuperación con un hilo fino de tráfico. Protege los pools de hilos y de conexiones del agotamiento y frena el fallo en cascada. Perjudica cuando los umbrales son demasiado estrictos, cuando el fallback es peor que el error, o cuando todas las instancias se abren a la vez y la dependencia nunca recibe tráfico suficiente para demostrar que se recuperó.

Cerrado, abierto, semiabierto. Cuentas los fallos en una ventana móvil, y en cuanto cruzas el umbral abres el circuito y fallas de inmediato durante un periodo de enfriamiento, y después dejas pasar unas pocas peticiones de sondeo para ver si la dependencia está sana otra vez. Lo importante de verdad es proteger tus propios recursos. Si un servicio aguas abajo tarda 30 segundos en dar timeout, todos tus hilos de trabajo acaban aparcados en él y tu servicio muere por algo que no era culpa tuya. Donde se tuerce es en el alcance y el ajuste. Teníamos un breaker configurado a nivel de servicio y no por dependencia, así que una llamada inestable de recomendaciones abría el circuito también para el checkout, lo que suponía una caída mucho mayor que la que estábamos evitando. La otra trampa es el goteo del semiabierto. Si todas las réplicas se abren a la vez y sondean poco, el servicio de abajo apenas ve tráfico y te quedas a oscuras mucho más tiempo del que duró el fallo real.