Degradación elegante ante un portal caído

Un portal provincial deja de responder a media mañana y vuelve cuatro horas más tarde. En ese rato la integración que lo consulta sigue recibiendo pedidos: pantallas que se abren, lotes programados, flotas que revisan un vehículo antes de despacharlo. La pregunta no es si el servicio se cae con la fuente, sino qué sigue ofreciendo mientras tanto.

Llamamos degradación elegante a tener esa respuesta decidida antes del incidente: qué funciones se mantienen, cuáles se apagan a propósito y con qué etiqueta viaja cada una. Lo contrario es improvisar bajo presión, y suele terminar en el peor resultado: una respuesta vacía que parece una buena noticia.

Ya tratamos qué devolver cuando una jurisdicción falla. Acá el foco está un paso antes: qué deja de hacer el sistema, en qué orden y hasta cuándo.

La escalera se define antes del incidente

Escribí los niveles con nombre propio, del más completo al más pobre. Una escalera razonable tiene cuatro escalones:

consulta en vivo contra la fuente, válida al momento en que se obtuvo;
último estado guardado, con la hora de obtención a la vista;
funciones que no dependen de esa fuente: historial, comprobantes, exportaciones y resultados de otras jurisdicciones;
indisponibilidad declarada, cuando no hay ni un estado previo para mostrar.

Lo importante de cada escalón es qué deja de prometer. El segundo no promete actualidad; el cuarto, nada sobre esa jurisdicción. Ninguno promete que el vehículo no tenga infracciones. Escrita de antemano, la escalera le dice a soporte qué está viendo el cliente.

Un dato viejo sirve si viaja con su edad

RFC 9111 prevé el campo Age para estimar cuánto pasó desde que una respuesta fue generada o validada en el origen, y es restrictivo con lo vencido: una caché sólo puede servir una respuesta rancia si ninguna directiva lo prohíbe y además está desconectada o tiene permiso del cliente o del origen. Aunque el estado guardado no salga de una caché HTTP, la disciplina se traslada: entregarlo es una excepción declarada, y viaja con su hora de obtención.

Esa marca cambia la conversación con quien consume. “No hay actas informadas” es una afirmación. “No había actas informadas cuando la fuente respondió, hace tres horas” es un dato con alcance: se puede auditar.

Con un matiz: la antigüedad del dato no es la actualidad del hecho. Un portal disponible también publica actas cargadas con demora. La edad declarada acota el riesgo que agrega la caída, no todo el riesgo.

Dejar de pedirle al portal caído

Cuando una fuente acumula fallas seguidas, insistir al ritmo normal agrega carga a algo quizá ya saturado y gasta el presupuesto de espera de cada consulta en un intento sin chances. Un corte de circuito —dejar de enviar tráfico en vivo por un plazo, servir el escalón siguiente y reabrir con unos pocos sondeos— protege a los dos lados.

Necesita tres parámetros documentados: qué cuenta como falla, cuánto dura el corte y cómo se reabre. Y una regla comercial que suele olvidarse: una consulta que nunca llegó a ejecutarse no debería consumir crédito.

Lo que el sistema deja de hacer, y cómo lo dice

Lo menos visible de la degradación no es lo que se devuelve, sino los efectos que se suspenden. Mientras la fuente está caída, el sistema no cierra un monitoreo ni marca el vehículo como verificado, no emite avisos de “sin infracciones” ni de deuda cancelada y no borra de un tablero actas que ya informó.

La ausencia de respuesta no es un cambio de estado. Un acta conocida ayer sigue existiendo aunque el portal no conteste.

Hacia afuera, RFC 9110 atribuye el 503 a una sobrecarga temporal o a un mantenimiento programado del propio servidor, y admite acompañarlo con Retry-After. Dos cuidados: la API no está indisponible porque lo esté una de varias fuentes, y el código habla del servicio, nunca del vehículo.

Para que el modo degradado sea programable hace falta un nombre estable. RFC 9457 define un formato de problema con identificador de tipo y campos de extensión: ahí entran qué modo está activo y a qué fuentes alcanza. Un texto libre no sirve como condición en el código de otro equipo.

La vuelta, el simulacro y qué verificar

Cuando el portal vuelve, todos los que esperaban tienden a volver juntos: la reapertura se dosifica como el corte. La reconciliación es por fuente, porque durante la caída pudo pagarse un acta y aparecer otra. Y el modo degradado tiene que apagarse solo: si queda pegado, el consumidor sigue descontando actualidad de un dato fresco.

Nada de esto se verifica leyendo código. Apagá una fuente en un entorno de prueba y comprobá:

que aparezca el escalón escrito y no un error genérico;
que ningún camino convierta la caída en “sin infracciones”;
que el modo degradado se vea en el tablero y en la respuesta;
que la vuelta lo limpie sola.

La caída de un portal oficial no se evita desde una integración. Lo que sí se decide de antemano es que no viaje disfrazada de resultado.

Metodología

Alcance: Criterios de diseño para el comportamiento de una integración de infracciones mientras una fuente oficial no responde. No cubre la operación interna de cada portal ni acuerdos de nivel de servicio con un proveedor puntual.
Unidad de análisis: Una consulta atendida durante la indisponibilidad de una fuente, con el nivel de servicio que le tocó y el momento en que se obtuvo el dato entregado.
Cobertura: Semántica de RFC 9110 y RFC 9111 sobre indisponibilidad temporal, espera sugerida y antigüedad de una representación almacenada, más el formato de problema de RFC 9457, al 29 de agosto de 2026.

Limitaciones

Los plazos de corte, la vigencia del estado guardado y el ritmo de reapertura dependen de cada fuente y deben calibrarse con mediciones propias.
Un escalón degradado reduce el daño de una caída, pero no reemplaza la verificación en la fuente oficial antes de una decisión irreversible.
La nota describe criterios de integración y no constituye asesoramiento jurídico sobre el valor de un estado consultado en un momento dado.

Fuentes

RFC 9110 — HTTP Semantics — RFC Editor (consultada el 2026-08-29)
RFC 9111 — HTTP Caching — RFC Editor (consultada el 2026-08-29)
RFC 9457 — Problem Details for HTTP APIs — RFC Editor (consultada el 2026-08-29)

Preguntas frecuentes

¿Degradación elegante quiere decir devolver una lista vacía?

No. Una lista vacía sin contexto es justamente el resultado que hay que evitar, porque se lee como ausencia de infracciones. Degradar consiste en entregar un escalón inferior identificado como tal, por ejemplo el último estado guardado con su hora de obtención o la indisponibilidad declarada de esa fuente.

¿Conviene responder 503 si se cae una sola jurisdicción?

En general no. RFC 9110 atribuye ese código a una sobrecarga temporal o a un mantenimiento programado del propio servidor, no a la caída de un tercero. Si la API respondió con el resto de las fuentes, un 503 total exagera el alcance de la falla. Es más honesto entregar la consulta y marcar esa fuente como no verificada.

¿Hasta cuándo se puede mostrar el último estado guardado?

No hay un plazo universal. Depende de con qué frecuencia cambia esa fuente y de qué decisión se toma con el dato. Lo que no es opcional es mostrar la hora de obtención y volver a consultar cuando la fuente se recupera. Un valor viejo sin fecha visible es peor que una indisponibilidad declarada.

¿El modo degradado se apaga solo cuando vuelve el portal?

Debería, y conviene probarlo. Un modo que queda pegado hace que el consumidor siga descontando actualidad de un dato que ya se actualizó. La vuelta también implica reconciliar por fuente, porque durante la caída pueden haberse pagado actas viejas o haber aparecido otras nuevas.

Degradación elegante cuando un portal cae