RTO y RPO convertidos en arquitectura

Cuando el desastre que se contempla es la caída de una región entera, la recuperación se hace en otra región, y hay cuatro formas de prepararla que se ordenan de menos a más costosa y de más lenta a más rápida. Copia y restauración: en la otra región solo hay copias de los datos y todo lo demás se vuelve a desplegar. Luz piloto: los datos ya están replicados y la infraestructura base existe, pero apagada; hay que encenderla. Espera tibia: hay una copia reducida de todo, ya funcionando. Activo-activo: dos regiones atienden tráfico a la vez.

La diferencia entre luz piloto y espera tibia suele confundirse. En la luz piloto la región de recuperación no puede atender una petición hasta que alguien enciende y despliega lo que falta; en la espera tibia ya atiende, con menos capacidad, y solo hay que subirla.

El RPO se cumple con la frecuencia de la copia o con el retraso de la replicación, no con la rapidez de la restauración. Una copia programada cada dos horas permite perder hasta dos horas de datos; una replicación asíncrona con un retraso máximo de unos minutos permite perder esos minutos. La comprobación es siempre la misma: comparar lo que se mide con lo que se prometió.

Abre la tabla objetivos. La última columna es lo que se mide hoy, en minutos; la tercera es el RPO prometido. Un servicio cumple si lo medido es igual o menor que lo prometido.

El RTO real de un ensayo es la suma de todos los pasos, desde la caída hasta que el servicio responde, incluidos los que no son técnicos: confirmar que la caída es real y decidir que se recupera cuentan igual que restaurar. Y se compara con el RTO prometido del servicio, no con el de otro.

Suma la columna minutos de la tabla ensayo_pagos_api y compárala con el RTO objetivo de pagos-api en la tabla objetivos.

Ante un RTO que no se cumple, la tentación es acelerar todo un poco. Es más eficaz mirar cuál es el paso grande y preguntarse si la arquitectura lo necesita. Restaurar una base desde una copia es lento por naturaleza: hay que reconstruir los datos. Mantener una réplica ya sincronizada en la región de recuperación y promoverla cuando haga falta es otra arquitectura —el paso de luz piloto o espera tibia— y cambia el orden de magnitud del paso.

Cada cambio de estrategia cuesta: la réplica funciona todo el año, no solo el día del desastre. Por eso se cambia donde el paso pesa más.

Una decisión de arquitectura se defiende con un número. Calamar probó el 2026-09-25 promover la réplica de su base del libro mayor en la región de recuperación; la tabla promocion_de_replica trae lo que tardó. Si pagos-api usara una réplica así en vez de restaurar desde la copia, ese paso se reemplazaría por la promoción y el resto del ensayo quedaría igual.