Hoe ontwerp je een multi-region DB voor HA en DR?

Question

IT Interview Practice · Accepted Answer

Repliceer de database over regio's en kies je topologie op behoefte: **active-passive** (één writer, een warme standby die het overneemt bij failover) voor eenvoud en sterke consistentie, of **active-active** (meerdere writers) voor lage write-latency ten koste van conflictresolutie — kies dan **sync versus async replicatie** om duurzaamheid tegen latency af te wegen, en definieer expliciete **RPO/RTO**-doelen die failover sturen.

```text
        ┌──────────── Regio A (primary) ────────────┐
writes ─▶ app ─▶ DB primary ──┐
                              │ replicatie
        ┌─────────────────────┼── async (RPO>0) ─────┐
        │                     └── sync (RPO=0, traag) │
        ▼                                             ▼
   Regio B standby                            (failover promoveert standby)
        │
   health check ──▶ bij verlies primary: promoveer + herwijs DNS/verkeer
```

## Active-passive versus active-active

**Active-passive** heeft één primary die writes afhandelt en standbys die alleen lezen; bij falen **promoveer** je een standby. Het is eenvoudig en vermijdt write-conflicten, maar de passieve capaciteit zit idle en failover heeft een gat. **Active-active** laat elke regio writes accepteren voor lokale latency en geen failover-promotie — maar twee regio's kunnen dezelfde row gelijktijdig bewerken, dus je *moet* conflicten oplossen (last-write-wins, CRDTs, of app-level merge). De meeste teams starten active-passive; active-active is voor globale write-latency die je echt niet anders kunt halen.

## Sync versus async replicatie

Dit is de kern-afweging tussen duurzaamheid en latency. **Synchroon:** de primary wacht tot de remote replica bevestigt vóór het committen — **RPO = 0** (geen dataverlies bij failover) maar elke write betaalt cross-region round-trip-latency (~tientallen ms), en als de replica onbereikbaar is, stallen writes. **Asynchroon:** de primary commit lokaal en verstuurt wijzigingen daarna — snelle writes, maar een regioverlies kan de laatste paar seconden verliezen (**RPO > 0**). Cross-region sync is vaak te traag, dus velen draaien async en accepteren een kleine RPO.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** hoeveel data je kunt verliezen — bepaald door sync versus async.
- **RTO (Recovery Time Objective):** hoe lang tot je terug bent — bepaald door hoe snel je falen detecteert en promoveert.
- Failover = detecteer (health checks) → promoveer standby → herwijs verkeer (DNS/global LB). Automatiseer het, maar bescherm tegen **split-brain** (beide regio's denken dat ze primary zijn) met een quorum/fencing token.

## Interviewperspectief

De peiling: begrijp je dat HA/DR een **afweging tussen consistentie, latency en dataverlies** is — niet "gewoon een replica toevoegen". Goed: active-passive met een standby. Uitstekend: je benoemt RPO/RTO, sync-versus-async-implicaties, en het split-brain-risico. Valkuil: beweren dat async nul dataverlies geeft, of aannemen dat failover direct en verliesvrij is.

## Afwegingen & faalmodi

- **Split-brain:** een netwerkpartitie promoveert twee primaries → divergente data. Gebruik quorum, fencing, of een witness-regio.
- **Failback is moeilijk:** nadat de oude primary terugkeert, is het reconcileren van divergente writes handmatig en foutgevoelig.
- **Kosten:** echte multi-region verdubbelt ruwweg de infra en voegt cross-region egress-bandbreedterekeningen toe.
- **Ongeteste failover faalt:** DR die nooit geoefend is werkt niet in de echte storing — draai game-days.

Active-passive versus active-active

Sync versus async replicatie

Failover, RPO & RTO

Interviewperspectief

Afwegingen & faalmodi

Gerelateerde vragen