Hvordan designer du en multi-region DB til HA og DR?

Question

IT Interview Practice · Accepted Answer

Replikér databasen over regioner og vælg din topologi efter behov: **active-passive** (én writer, en warm standby der overtager ved failover) for enkelhed og stærk konsistens, eller **active-active** (flere writers) for lav write-latency på bekostning af conflict resolution — vælg derefter **sync vs async replication** for at afveje durability mod latency, og definér eksplicitte **RPO/RTO**-mål der driver 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** har én primary der håndterer writes og standbys der kun læser; ved fejl **promoverer** du en standby. Det er enkelt og undgår write-konflikter, men den passive kapacitet sidder ledig og failover har et gab. **Active-active** lader hver region modtage writes for lokal latency og ingen failover-promotion — men to regioner kan redigere samme row samtidigt, så du *skal* løse konflikter (last-write-wins, CRDTs, eller merge på app-niveau). De fleste teams starter active-passive; active-active er til global write-latency du reelt ikke kan møde på anden vis.

## Sync vs async replication

Dette er kerne-durability/latency-trade-off'et. **Synkron:** primary'en venter på, at remote-replicaen ack'er før commit — **RPO = 0** (intet datatab ved failover) men hver write betaler cross-region round-trip-latency (~titusinder af ms), og hvis replicaen er uopnåelig, stalder writes. **Asynkron:** primary'en committer lokalt og sender ændringer bagefter — hurtige writes, men et region-tab kan miste de sidste par sekunder (**RPO > 0**). Cross-region sync er ofte for langsom, så mange kører async og accepterer en lille RPO.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** hvor meget data du kan miste — sat af sync vs async.
- **RTO (Recovery Time Objective):** hvor længe til du er tilbage — sat af hvor hurtigt du detekterer fejl og promoverer.
- Failover = detektér (health checks) → promovér standby → repoint trafik (DNS/global LB). Automatisér det, men vogt mod **split-brain** (begge regioner tror de er primary) med et quorum/fencing token.

## Interview-perspektiv

Undersøgelsen: forstår du, at HA/DR er et **trade-off mellem konsistens, latency og datatab** — ikke "bare tilføj en replica". Godt: active-passive med en standby. Fremragende: du angiver RPO/RTO, sync-vs-async-implikationer, og split-brain-risikoen. Fælde: at hævde async giver nul datatab, eller at antage failover er øjeblikkelig og tabsfri.

## Trade-offs & fejlmåder

- **Split-brain:** en netværkspartition promoverer to primaries → divergerende data. Brug quorum, fencing eller en witness-region.
- **Failback er svært:** efter den gamle primary vender tilbage, er afstemning af divergerende writes manuel og fejlbehæftet.
- **Omkostning:** ægte multi-region fordobler groft infra og tilføjer cross-region egress-båndbreddebills.
- **Utestet failover fejler:** DR der aldrig er drillet vil ikke virke i det rigtige udfald — kør game-days.

Active-passive vs active-active

Sync vs async replication

Failover, RPO & RTO

Interview-perspektiv

Trade-offs & fejlmåder

Relaterede spørgsmål