API y empresas

Circuit breaker sobre una fuente inestable

Cuando un portal empieza a fallar, insistir empeora las dos puntas. Un corte deliberado y temporal de las llamadas a esa fuente protege al organismo y devuelve antes una respuesta honesta.

Por Marco Ferreiro ·

Tablero eléctrico de chapa gris con una hilera de llaves térmicas: una palanca quedó bajada y las demás siguen levantadas, bajo luz natural lateral.

Una fuente rara vez se cae de golpe: primero tarda más, después devuelve indisponibilidad temporal en algunas llamadas y al rato casi todo termina en tiempo de espera agotado. Insistir empeora las dos puntas: de un lado se llenan los hilos esperando timeouts perdidos, del otro llega más tráfico al organismo justo cuando menos capacidad tiene.

La política de reintentos no alcanza: vive dentro de un mismo pedido y no recuerda nada del anterior. Lo que falta es memoria entre llamadas. Un circuit breaker es esa memoria: un estado por fuente que, cuando las fallas recientes superan un umbral, deja de llamar por un rato y falla rápido. No arregla la fuente; compra tiempo y evita convertir una caída ajena en una respuesta falsa.

Qué cuenta como falla para el corte

El contador no es “todo lo que no fue exitoso”. Lo alimentan las señales que hablan de la capacidad de la fuente, no del contenido del pedido: la conexión que no se establece, el tiempo de espera agotado y la indisponibilidad que RFC 9110 describe como sobrecarga o mantenimiento pasajeros. La tabla completa de causas ya está en errores que conviene reintentar; el corte no la reemplaza, decide si vale la pena llegar hasta ahí.

Quedan afuera tres casos que se cuelan seguido:

El último es el más caro: contarlo como falla abre el corte por algo que se corrige bajando el ritmo, no esperando a la fuente, como detalla la nota sobre rate limits interpretables.

Un corte por fuente y por operación

Un corte global convierte la caída de un municipio en la caída del servicio entero. La llave debería ser la fuente junto con la operación: consultar por dominio y descargar un comprobante pueden compartir portal y no capacidad. Y cuando varias jurisdicciones corren sobre la misma infraestructura sus fallas se correlacionan: la llave tiene que parecerse a lo que se cae, no al nombre que se ve en pantalla.

Otro detalle es dónde vive el estado. Si sólo existe en la memoria de cada réplica, cada proceso aprende por su cuenta y la fuente recibe tantas ráfagas como instancias haya. Compartirlo cuesta, pero protege al organismo, no sólo al proceso.

Los tres estados y la sonda

El estado cerrado deja pasar las llamadas y registra cómo terminaron. El abierto no llama: responde de inmediato con el motivo. El semiabierto deja pasar una sonda para ver si tiene sentido volver.

El umbral conviene expresarlo como proporción sobre una ventana reciente, con un mínimo de llamadas: sin ese mínimo, dos consultas de madrugada y un timeout cortan una fuente sana.

La sonda es lo que más se descuida. Debería ser una llamada real de la misma operación, de a una por vez, y no un chequeo superficial de la portada. Repetirla es defendible porque una consulta de infracciones tiene la semántica de sólo lectura que RFC 9110 llama segura: el cliente no pide ni espera un cambio de estado en el servidor. Esa definición admite igual efectos del otro lado, como el registro del acceso: la sonda no modifica nada, pero cuesta. Tampoco hace falta inventar un dominio de prueba: sirve la próxima consulta genuina.

Si la fuente publicó una espera sugerida, ese valor es mejor piso que uno propio. Y una sonda exitosa habilita a volver, no a descargar la cola acumulada sobre un servicio que recién se recupera.

Lo que ve quien integra

Fallar rápido no puede parecerse a un resultado. Con el corte abierto, la respuesta es una parcial con esa fuente marcada como no consultada, en la línea de qué devolver cuando falla una jurisdicción.

El motivo tiene que ser una llave comparable, no una frase. RFC 9457 pide que el consumidor tome como identificador primario el tipo del problema —una URI— y deja el título como texto orientativo, que puede llegar traducido. Al corte le conviene un tipo propio: “no se consultó porque el circuito estaba abierto” no es lo mismo que “la fuente falló en esta llamada”.

Qué revisar antes de encenderlo

Registrá cada transición como un evento: fuente, operación, estado nuevo, motivo, ventana y hora con zona horaria, sin patente ni CUIT en las etiquetas. Probá el camino de vuelta con fallas inyectadas: el defecto habitual no es que el corte no abra sino que no cierre nunca. La sonda queda bloqueada por el control de ritmo, o el contador no se reinicia.

Un corte abierto que nadie mira es una caída disfrazada de normalidad. Conviene alertar por tiempo abierto acumulado por fuente y revisar si el umbral se disparó con evidencia o con tres llamadas desafortunadas.

Metodología

Alcance
Diseño de un corte deliberado de llamadas hacia fuentes externas en una consulta de infracciones multi-jurisdicción, independiente de la biblioteca o el lenguaje. No cubre la clasificación de errores individuales ni la política de reintentos dentro de un mismo pedido.
Unidad de análisis
La fuente consultada junto con la operación que se le pide, y las transiciones de estado observadas entre llamadas consecutivas.
Cobertura
Semántica de HTTP sobre métodos seguros, indisponibilidad temporal, espera sugerida y exceso de solicitudes, más el formato de error estructurado con tipo estable, según los RFC citados al 29 de agosto de 2026.

Limitaciones

Fuentes

Preguntas frecuentes

¿Un circuit breaker reemplaza a la política de reintentos?

No. El reintento decide qué hacer con un pedido que ya falló; el corte decide si conviene hacer el pedido siguiente. Trabajan juntos: sin reintentos se abandona ante una falla pasajera, y sin corte se reintenta contra una fuente que ya dejó de responder.

¿Un rechazo por exceso de ritmo debería abrir el corte?

Como falla de la fuente, no. El 429 que define RFC 6585 informa que se enviaron demasiadas solicitudes en un período, y eso se corrige bajando el ritmo o esperando el valor que la respuesta indique cuando lo trae. Si igual se quiere frenar, conviene un control de ritmo separado, con su propio contador y su propio motivo.

¿Qué devuelve la API mientras el corte está abierto?

Una consulta parcial con esa fuente marcada como no consultada y un motivo estable, más el momento estimado de reintento si existe. Nunca una lista vacía presentada como resultado: no haber consultado y haber consultado sin encontrar actas son dos cosas distintas.

¿Alcanza con un healthcheck para decidir la reapertura?

Que la portada de un portal responda no prueba que el camino de consulta funcione. La sonda debería ejercitar la misma operación que el corte protege, de a una por vez, para que el resultado signifique algo.

Notas relacionadas