Migreer een database van 10TB met zero downtime: wat is het plan?

Question

IT Interview Practice · Accepted Answer

**Dual-write naar oud en nieuw, backfill de historie op de achtergrond, gebruik CDC om de staart in te halen, verifieer met shadow reads, flip dan de reads atomair — met een rollback-pad bij elke stap.** Je haalt de app nooit offline; je draait beide databases parallel tot de nieuwe aantoonbaar identiek is, en cut dan over.

## Architectuur

```text
        ┌── write ──▶ OUDE DB (source of truth) ──CDC (Debezium)──┐
 App ───┤                                                        ▼
        └── write ──▶ NIEUWE DB ◀──── backfill-job (historische rows)
                        │
   shadow reads (vergelijk OUD vs NIEUW) ─▶ diff-metrics ─▶ atomaire cutover ─▶ NIEUW is truth
                                                          (flip flag; rollback = terugflippen)
```

## Hoe het werkt

1. **Dual-write.** De app schrijft elke wijziging naar zowel OUD als NIEUW. Nieuwe rows blijven vanaf nu in sync; alleen historie ontbreekt.
2. **Backfill.** Een achtergrond-job kopieert historische rows in batches (getthrottled om prod te beschermen). Gebruik `INSERT ... ON CONFLICT DO NOTHING` zodat het idempotent en veilig herhaalbaar is.
3. **CDC-inhaalslag.** Dual-write kan rows missen die tijdens het inschakelen zijn geschreven. **Debezium** streamt de WAL/binlog van de OUDE DB en replayt elke wijziging, wat het gat dicht dat de backfill niet kan.
4. **Shadow reads.** Lees parallel uit NIEUW naast OUD, **vergelijk resultaten**, en emit een diff-metric. Nul diffs over tijd = NIEUW is betrouwbaar.
5. **Cutover.** Flip een feature flag zodat reads (daarna writes) naar NIEUW gaan. Het is een config-wijziging, geen deploy — direct, en **omkeerbaar door terug te flippen**.

## Interviewperspectief

De interviewer wil **hoe je geen dataverlies en geen downtime garandeert**, en of je een **rollback** hebt. Goede antwoorden noemen dual-write; uitstekende voegen **CDC om het race-venster te vangen** toe, **shadow reads om te verifiëren vóór vertrouwen**, en een **atomaire, omkeerbare flag-flip**. De klassieke valkuil is "backfill dan omschakelen" zonder verificatie — je ontdekt de mismatch nadat gebruikers erop stuiten, zonder weg terug.

## Afwegingen & faalmodi

- **Dual-write-consistentie.** Als de NIEUWE write faalt maar OUD slaagt, divergeren ze. Maak OUD autoritatief en laat CDC NIEUW repareren, in plaats van de request van de gebruiker te laten falen.
- **Kosten & complexiteit.** Twee databases + CDC + backfill draaien is duur en operationeel zwaar — alleen gerechtvaardigd voor grote, kritieke stores.
- **Schemawijzigingen** tijdens migratie vermenigvuldigen risico; bevries het schema tot cutover.
- **Backfill-belasting.** Een ongethrottelde backfill kan prod-I/O verzadigen en een storing veroorzaken — het tegenovergestelde van het doel; batch en rate-limit.
- **Rollback-venster.** Blijf dual-writen (nu NIEUW→OUD) dagen na cutover zodat je kunt terugflippen als een latente bug opduikt. Ontmantel OUD pas daarna.
- **Wanneer niet:** een kleine DB met een onderhoudsvenster heeft dit niet nodig — een `pg_dump`/restore van 30 minuten is eenvoudiger en veiliger dan een CDC-pipeline.

Architectuur

Hoe het werkt

Interviewperspectief

Afwegingen & faalmodi

Gerelateerde vragen