Disaster Recovery (DR)

Toku cuenta con un plan de recuperación ante desastres (DR) que se activa ante una contingencia mayor en la infraestructura principal. Mientras el DR está activo, la plataforma deja de procesar operaciones y responde de forma controlada en todos sus canales.

Esta página describe qué vas a observar como integrador durante ese período, para que puedas distinguir un DR de una caída y manejarlo correctamente desde tu integración.

Qué responde cada canal

Respuesta de la API HTTP

Durante el DR, toda petición a un endpoint de negocio recibe 503 Service Unavailable. El cuerpo puede tener una de estas dos formas:

{
  "error": "service_unavailable",
  "message": "DR mode enabled. This is a fallback response."
}

{
  "status": "disaster_recovery",
  "message": "Toku se encuentra en modo Disaster Recovery. Temporalmente no es posible procesar operaciones."
}

⚠️

No uses el cuerpo como discriminador

Ambos cuerpos significan lo mismo y cuál recibes depende del endpoint. Lo estable es el status 503: trata cualquier 503 de un dominio de Toku como servicio temporalmente no disponible.

Notas de comportamiento:

• Autenticación: durante el DR la verificación de credenciales no se ejecuta. Una petición sin credenciales válidas recibe 503, no 401 ni 403.
• CORS: el preflight OPTIONS no falla. El navegador recibe los headers CORS correctamente y luego ve el 503 de la petición real.

El significado de cada status, incluido el 503, vive en Códigos HTTP de respuesta.

SFTP

El canal SFTP se deshabilita durante el DR, pero el protocolo no transporta un mensaje de error descriptivo:

⚠️

Un fallo de login por DR es indistinguible de una credencial inválida.

Si tus cargas por SFTP empiezan a fallar con error de autenticación, revisa primero el estado de la plataforma antes de rotar credenciales.

Transición y propagación

La activación y la desactivación del DR no son instantáneas ni atómicas. Durante la ventana de transición pueden convivir respuestas normales y respuestas de contingencia: una misma integración puede recibir 200 y 503 de forma alternada por algunos minutos, dependiendo entre otras cosas del caché DNS.

Recomendaciones para tu integración

• Reintenta con backoff exponencial ante 503, en vez de fallar de inmediato o reintentar en loop apretado.
• No marques operaciones como fallidas de forma definitiva por un 503: la operación no llegó a procesarse y puede reintentarse cuando la plataforma se restablezca.
• Usa idempotencia en los reintentos posteriores para evitar duplicados si un 503 se dio durante la ventana de transición.
• Suscríbete a la página de estado de Toku para enterarte de la activación y del restablecimiento.