Migra un database da 10TB con zero downtime: qual è il piano?

Question

IT Interview Practice · Accepted Answer

**Fai dual-write su vecchio e nuovo, fai backfill della storia in background, usa il CDC per recuperare la coda, verifica con shadow read, poi commuta le letture atomicamente — con un percorso di rollback a ogni passo.** Non spegni mai l'app; fai girare entrambi i database in parallelo finché il nuovo non è dimostrabilmente identico, poi fai cutover.

## Architettura

```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)
```

## Come funziona

1. **Dual-write.** L'app scrive ogni cambiamento sia su OLD sia su NEW. Le nuove righe restano sincronizzate d'ora in poi; manca solo la storia.
2. **Backfill.** Un job in background copia le righe storiche a batch (con throttling per proteggere la prod). Usa `INSERT ... ON CONFLICT DO NOTHING` così che sia idempotente e sicuro da ri-eseguire.
3. **CDC catch-up.** Il dual-write può perdere righe scritte durante l'attivazione. **Debezium** che fa streaming del WAL/binlog di OLD ripete ogni cambiamento, colmando il gap che il backfill non può.
4. **Shadow read.** Leggi da NEW in parallelo con OLD, **confronta i risultati** ed emetti una metrica di diff. Zero diff nel tempo = NEW è affidabile.
5. **Cutover.** Commuta un feature flag così che le letture (poi le scritture) vadano su NEW. È un cambio di configurazione, non un deploy — istantaneo, e **reversibile ricommutando**.

## Prospettiva del colloquio

L'intervistatore vuole capire **come garantisci nessuna perdita di dati e nessun downtime**, e se hai un **rollback**. Le buone risposte menzionano il dual-write; le eccellenti aggiungono il **CDC per catturare la finestra di race**, le **shadow read per verificare prima di fidarti**, e una **commutazione del flag atomica e reversibile**. La trappola classica è "backfill poi switch" senza verifica — scopri la discrepanza dopo che gli utenti l'hanno colpita, senza via di ritorno.

## Compromessi e modalità di guasto

- **Consistenza del dual-write.** Se la scrittura su NEW fallisce ma OLD riesce, divergono. Rendi OLD autorevole e lascia che il CDC ripari NEW, invece di far fallire la richiesta dell'utente.
- **Costo e complessità.** Far girare due database + CDC + backfill è costoso e operativamente pesante — giustificato solo per store grandi e critici.
- **I cambi di schema** durante la migrazione moltiplicano il rischio; congela lo schema fino al cutover.
- **Carico del backfill.** Un backfill senza throttling può saturare l'I/O della prod e causare un'interruzione — l'opposto dell'obiettivo; fai batch e rate-limit.
- **Finestra di rollback.** Continua il dual-write (ora NEW→OLD) per giorni dopo il cutover così da poter ricommutare se emerge un bug latente. Solo allora dismetti OLD.
- **Quando non farlo:** un DB piccolo con una finestra di manutenzione non richiede questo — un `pg_dump`/restore da 30 minuti è più semplice e sicuro di una pipeline CDC.

Architettura

Come funziona

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate