¿Cómo diseñas una DB multi-region para HA y DR?

Question

IT Interview Practice · Accepted Answer

Replica la base de datos entre regiones y elige tu topología según la necesidad: **active-passive** (un writer, un warm standby que toma el relevo en el failover) para simplicidad y consistencia fuerte, o **active-active** (múltiples writers) para baja latencia de escritura a costa de la resolución de conflictos — luego elige **replicación sync vs async** para intercambiar durabilidad por latencia, y define objetivos explícitos de **RPO/RTO** que dirijan el failover.

```text
        ┌──────────── Region A (primary) ────────────┐
writes ─▶ app ─▶ DB primary ──┐
                              │ replication
        ┌─────────────────────┼── async (RPO>0) ─────┐
        │                     └── sync (RPO=0, slow)  │
        ▼                                             ▼
   Region B standby                            (failover promotes standby)
        │
   health check ──▶ on primary loss: promote + repoint DNS/traffic
```

## Active-passive vs active-active

**Active-passive** tiene un primary que maneja las escrituras y standbys que solo leen; ante un fallo **promueves** un standby. Es simple y evita conflictos de escritura, pero la capacidad pasiva está inactiva y el failover tiene un hueco. **Active-active** deja que cada región acepte escrituras para latencia local y sin promoción de failover — pero dos regiones pueden editar la misma fila concurrentemente, así que *debes* resolver conflictos (last-write-wins, CRDTs, o merge a nivel de app). La mayoría de los equipos empiezan active-passive; active-active es para una latencia de escritura global que realmente no puedes cumplir de otro modo.

## Replicación sync vs async

Esta es la compensación central de durabilidad/latencia. **Síncrona:** el primary espera a que la réplica remota confirme antes de comprometer — **RPO = 0** (sin pérdida de datos en el failover) pero cada escritura paga la latencia del round-trip cross-region (~decenas de ms), y si la réplica es inalcanzable, las escrituras se detienen. **Asíncrona:** el primary compromete localmente y envía los cambios después — escrituras rápidas, pero una pérdida de región puede perder los últimos segundos (**RPO > 0**). El sync cross-region suele ser demasiado lento, así que muchos corren async y aceptan un RPO pequeño.

## Failover, RPO y RTO

- **RPO (Recovery Point Objective):** cuántos datos puedes perder — fijado por sync vs async.
- **RTO (Recovery Time Objective):** cuánto hasta que vuelves — fijado por qué tan rápido detectas el fallo y promueves.
- Failover = detectar (health checks) → promover el standby → reapuntar el tráfico (DNS/global LB). Automatízalo, pero protégete contra el **split-brain** (ambas regiones creen ser primary) con un quorum/fencing token.

## Perspectiva de la entrevista

El sondeo: ¿entiendes que HA/DR es una **compensación entre consistencia, latencia y pérdida de datos** — no "solo añade una réplica"? Bueno: active-passive con un standby. Excelente: declaras RPO/RTO, las implicaciones de sync-vs-async, y el riesgo de split-brain. Trampa: afirmar que async da cero pérdida de datos, o asumir que el failover es instantáneo y sin pérdida.

## Compensaciones y modos de fallo

- **Split-brain:** una partición de red promueve dos primaries → datos divergentes. Usa quorum, fencing, o una región testigo.
- **El failback es difícil:** tras volver el viejo primary, reconciliar las escrituras divergentes es manual y propenso a errores.
- **Coste:** el verdadero multi-region duplica aproximadamente la infra y añade facturas de egress bandwidth cross-region.
- **Un failover no probado falla:** un DR que nunca se ensaya no funcionará en la caída real — haz game-days.

Active-passive vs active-active

Replicación sync vs async

Failover, RPO y RTO

Perspectiva de la entrevista

Compensaciones y modos de fallo

Preguntas relacionadas