Recuperación ante desastres activo-activo vs. activo-pasivo: ¿en qué se diferencian y cuál es el verdadero intercambio de RTO/RPO?
El RTO y el RPO, no el nombre de la topología, son lo que realmente debería juzgar un diseño de recuperación ante desastres.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
Recuperación ante desastres activo-activo vs. activo-pasivo: ¿en qué se diferencian y cuál es el verdadero intercambio de RTO/RPO?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#Dos números antes de diseñar nada
Antes de comparar topologías, hay que fijar los dos números que realmente definen un requisito de recuperación ante desastres, porque "necesitamos alta disponibilidad" no es una especificación.
RTO (Recovery Time Objective) responde: ¿cuánto tiempo puede estar caído el sistema antes de que el negocio sufra un daño real? Si el checkout puede estar offline 15 minutos sin que nadie fuera de la empresa lo note, tu RTO es de 15 minutos. RPO (Recovery Point Objective) responde: ¿cuántos datos puedes permitirte perder, medidos en tiempo? Si tu último checkpoint de backup o replicación fue 5 minutos antes del desastre, y eso es aceptable, tu RPO es de 5 minutos.
Estos dos números —no las palabras "activo-activo" o "activo-pasivo"— son contra lo que debería juzgarse un diseño de recuperación ante desastres. Un sistema activo-activo maravillosamente diseñado que igual pierde 30 segundos de escrituras al hacer failover tiene un RPO de 30 segundos: di ese número en voz alta en la revisión de diseño, no solo el nombre de la topología.
#Activo-pasivo: una región trabaja, una región espera
En activo-pasivo, una región (la primaria) atiende todo el tráfico de producción. Una segunda región (el standby) recibe datos replicados continuamente pero no atiende nada: existe únicamente para ser promovida si la primaria muere.
La secuencia de failover es: detectar que la primaria está caída (health checks, normalmente con un retraso deliberado para evitar falsos positivos por un tropiezo transitorio), promover el standby a primaria (sacar su base de datos del modo solo-lectura, actualizar su configuración) y redirigir el tráfico (cambio de DNS o de balanceador de carga). Cada uno de esos tres pasos toma tiempo real —solo la detección suele tomar entre 30 y 90 segundos si se quiere evitar falsos positivos—, así que un RTO realista en activo-pasivo se mide en minutos, no en segundos, incluso con automatización. El RPO está acotado por el retraso de la replicación: si la replicación es asíncrona (el caso común, porque la replicación síncrona entre regiones es lenta), cualquier escritura que no haya llegado al standby cuando murió la primaria se pierde.
El atractivo es la simplicidad: solo una cosa escribe en la base de datos, así que no hay que diseñar resolución de conflictos ni protegerse de un split-brain, y el modo de falla es bien entendido. El costo es que la capacidad de la región standby permanece mayormente ociosa, y el failover es un evento discreto, ensayado de vez en cuando, en lugar de algo que ocurre de forma rutinaria; lo cual también significa que es lo más probable que esté roto justo cuando lo necesitas, porque es el camino de código menos ejercitado de todo el sistema.
#Activo-activo: ambas regiones trabajan, todo el tiempo
En activo-activo, ambas regiones atienden tráfico de producción en vivo simultáneamente, y ambas aceptan escrituras.
Como ambas regiones aceptan escrituras sobre el mismo conjunto de datos lógico, ahora necesitas una estrategia de resolución de conflictos para el caso en que el mismo registro se modifique en ambas regiones antes de que la replicación se ponga al día: gana-la-última-escritura por timestamp, relojes vectoriales, CRDTs para tipos de datos que se fusionan limpiamente (contadores, conjuntos), o lógica de fusión a nivel de aplicación. Si una región falla, no hay un paso de "promoción": la otra región ya estaba atendiendo tráfico, así que el RTO para los usuarios de la región caída es cercano a cero (acotado principalmente por qué tan rápido tu enrutador se da cuenta y deja de mandarle tráfico). El RPO también puede acercarse a cero para los datos que nunca necesitaron fusión entre regiones, pero cualquier escritura que estuviera en vuelo hacia la región caída en el momento de la falla realmente se pierde, a menos que también haya sido confirmada de forma síncrona en otro lugar.
#El intercambio, lado a lado
| Activo-Pasivo | Activo-Activo | |
|---|---|---|
| RTO típico | Minutos (detección + promoción + cambio de DNS) | Segundos (el tráfico ya fluye hacia la región sana) |
| RPO típico | Acotado por el retraso de la replicación asíncrona; cercano a cero solo con replicación síncrona | Puede acercarse a cero para escrituras sin conflicto; las escrituras en conflicto necesitan una política de resolución |
| ¿Necesita resolución de conflictos? | No — un solo escritor | Sí — este es el problema de ingeniería difícil |
| Capacidad ociosa | La región standby está mayormente ociosa | Sin capacidad ociosa — ambas regiones hacen trabajo útil |
| ¿Con qué frecuencia se prueba el failover? | Se ensaya periódicamente (game days); los failovers reales son eventos raros | Nunca hace "failover" en el sentido tradicional — el enrutamiento solo cambia de peso |
| Mejor encaje | La mayoría de los negocios; requisitos de consistencia fuerte; guardia más simple | Negocios donde minutos de caída cuestan dinero real, y el modelo de datos tolera consistencia eventual o se fusiona limpiamente |
#Cómo elegir entre ambos
La respuesta honesta en una entrevista rara vez es "siempre activo-activo": esa es la respuesta que suena sofisticada pero ignora el costo. Parte del RTO/RPO que el negocio realmente necesita, revisa si el modelo de datos puede tolerar conflictos de múltiples escritores (un libro contable estricto con invariantes de partida doble es un candidato mucho más difícil para activo-activo que el contador de "me gusta" de un feed social), y solo entonces elige la topología. Muchos sistemas terminan en un híbrido: activo-activo para datos sin estado, idempotentes y fáciles de fusionar (sesiones, cachés, catálogos de solo lectura intensiva) y activo-pasivo para la porción pequeña de datos con consistencia fuerte y difíciles de fusionar (pagos, libros contables de inventario).
🧠 Check your understanding
0/2 · 0/2 answered1. Un libro contable de pagos necesita consistencia estricta y no puede tolerar que escrituras en conflicto se fusionen automáticamente. ¿Qué topología de recuperación ante desastres le conviene más?
2. ¿Qué acota principalmente el RPO en una configuración activo-pasivo con replicación asíncrona?