Migrar una base de datos de 10TB con cero downtime: ¿cuál es el plan?

Question

IT Interview Practice · Accepted Answer

**Haz dual-write a la vieja y la nueva, rellena el historial en background, usa CDC para alcanzar el rezago, verifica con shadow reads, luego cambia las lecturas de forma atómica — con una ruta de rollback en cada paso.** Nunca bajas la app; corres ambas bases de datos en paralelo hasta que la nueva sea demostrablemente idéntica, luego haces cutover.

## Arquitectura

```text
        ┌── write ──▶ OLD DB (source of truth) ──CDC (Debezium)──┐
 App ───┤                                                        ▼
        └── write ──▶ NEW DB ◀──── backfill job (historical rows)
                        │
   shadow reads (compare OLD vs NEW) ─▶ diff metrics ─▶ atomic cutover ─▶ NEW is truth
                                                          (flip flag; rollback = flip back)
```

## Cómo funciona

1. **Dual-write.** La app escribe cada cambio en OLD y NEW. Las filas nuevas quedan sincronizadas desde ahora; solo falta el historial.
2. **Backfill.** Un job en background copia las filas históricas por lotes (throttled para proteger prod). Usa `INSERT ... ON CONFLICT DO NOTHING` para que sea idempotente y seguro de re-ejecutar.
3. **CDC catch-up.** El dual-write puede perder filas escritas durante el encendido del switch. **Debezium** transmitiendo el WAL/binlog de la OLD DB hace replay de cada cambio, cerrando el hueco que el backfill no puede.
4. **Shadow reads.** Lee de NEW en paralelo con OLD, **compara resultados**, y emite una métrica de diff. Cero diffs a lo largo del tiempo = NEW es de confianza.
5. **Cutover.** Cambia un feature flag para que las lecturas (luego escrituras) vayan a NEW. Es un cambio de config, no un deploy — instantáneo, y **reversible volviendo a cambiarlo**.

## Perspectiva de la entrevista

El entrevistador quiere **cómo garantizas cero pérdida de datos y cero downtime**, y si tienes un **rollback**. Las buenas respuestas mencionan dual-write; las excelentes añaden **CDC para atrapar la ventana de carrera**, **shadow reads para verificar antes de confiar**, y un **cambio de flag atómico y reversible**. La trampa clásica es "rellena y luego cambia" sin verificación — descubres el desajuste después de que los usuarios lo golpeen, sin vuelta atrás.

## Compensaciones y modos de fallo

- **Consistencia del dual-write.** Si la escritura en NEW falla pero OLD tiene éxito, divergen. Haz OLD autoritativo y deja que CDC repare NEW, en lugar de fallar la request del usuario.
- **Coste y complejidad.** Correr dos bases de datos + CDC + backfill es caro y operativamente pesado — justificado solo para stores grandes y críticos.
- **Los cambios de schema** durante la migración multiplican el riesgo; congela el schema hasta el cutover.
- **Carga del backfill.** Un backfill sin throttle puede saturar el I/O de prod y causar una caída — lo opuesto al objetivo; hazlo por lotes y con rate-limit.
- **Ventana de rollback.** Sigue haciendo dual-write (ahora NEW→OLD) durante días tras el cutover para poder volver atrás si aflora un bug latente. Solo entonces desmantela OLD.
- **Cuándo no:** una DB pequeña con una ventana de mantenimiento no necesita esto — un `pg_dump`/restore de 30 minutos es más simple y seguro que un pipeline CDC.

Arquitectura

Cómo funciona

Perspectiva de la entrevista

Compensaciones y modos de fallo

Preguntas relacionadas