Alta disponibilidad y proveedores alternos

En la pasarela, cada ruta agrupa aplicaciones con un proveedor principal y una lista de alternos. Si el principal falla, la pasarela reintenta y, si sigue fallando, pasa al siguiente de la lista. Para no castigar a un proveedor caído, se usa un cortocircuito: tras varios errores seguidos deja de mandarle tráfico durante un tiempo y luego prueba de nuevo.

Lo que se olvida es que un alterno no es una copia del principal: es otra empresa, con otro contrato, otra región de proceso y otra aprobación para cada clase de datos. Un alterno solo es válido para una ruta si está aprobado para la clase de datos que esa ruta lleva, y si las mismas reglas de filtrado se le aplican igual. Si no hay ningún alterno aprobado, lo correcto es fallar con un mensaje claro, no mandar los datos a cualquiera.

Cruza cada ruta con su clase de datos, cada clase con los proveedores aprobados y el resultado con lo que de verdad ocurrió durante la caída.

El comité de privacidad necesita el volumen exacto para decidir si hay que notificar. Suma solo lo que llegó a un proveedor no aprobado para la clase de datos que llevaba; los intentos fallidos contra el principal no entregaron nada.

Reintentar ayuda con un error pasajero. Contra un proveedor caído, muchos reintentos sin espera multiplican la carga: cada petición de la aplicación se convierte en varias, el proveedor acaba limitando a toda la organización y el daño alcanza a rutas que estaban bien. Por eso los reintentos se limitan, se espacian cada vez más y se combinan con un cortocircuito.

Con lo que encontraste, decide qué cambio de la configuración recomiendas para la próxima caída.