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

Question

IT Interview Practice · Accepted Answer

Replikér databasen over regioner og velg topologien ut fra behov: **active-passive** (én writer, en warm standby som tar over ved failover) for enkelhet og sterk konsistens, eller **active-active** (flere writere) for lav write-latency på bekostning av konfliktløsning — velg deretter **sync vs async replikering** for å veksle durability mot latency, og definer eksplisitte **RPO/RTO**-mål som driver failover.

```text
        ┌──────────── Region A (primary) ────────────┐
writes ─▶ app ─▶ DB primary ──┐
                              │ replikering
        ┌─────────────────────┼── async (RPO>0) ─────┐
        │                     └── sync (RPO=0, treg)  │
        ▼                                             ▼
   Region B standby                            (failover promoterer standby)
        │
   health check ──▶ ved primary-tap: promoter + repoint DNS/trafikk
```

## Active-passive vs active-active

**Active-passive** har én primary som håndterer writes og standbys som kun leser; ved feil **promoterer** du en standby. Det er enkelt og unngår write-konflikter, men den passive kapasiteten sitter idle og failover har et gap. **Active-active** lar hver region akseptere writes for lokal latency og ingen failover-promotering — men to regioner kan redigere samme rad samtidig, så du *må* løse konflikter (last-write-wins, CRDT-er, eller merge på app-nivå). De fleste team starter active-passive; active-active er for global write-latency du genuint ikke kan møte på andre måter.

## Sync vs async replikering

Dette er den sentrale durability/latency-avveiningen. **Synkron:** primaryen venter på at remote-replica ack-er før commit — **RPO = 0** (ingen datatap ved failover) men hver write betaler cross-region round-trip-latency (~titalls ms), og hvis replica-en er unåbar, stopper writes. **Asynkron:** primaryen committer lokalt og sender endringer etterpå — raske writes, men et region-tap kan miste de siste sekundene (**RPO > 0**). Cross-region sync er ofte for tregt, så mange kjører async og aksepterer en liten RPO.

## Failover, RPO og RTO

- **RPO (Recovery Point Objective):** hvor mye data du kan miste — satt av sync vs async.
- **RTO (Recovery Time Objective):** hvor lenge til du er tilbake — satt av hvor raskt du detekterer feil og promoterer.
- Failover = detekter (health checks) → promoter standby → repoint trafikk (DNS/global LB). Automatiser det, men vokt mot **split-brain** (begge regioner tror de er primary) med et quorum/fencing-token.

## Intervjuperspektiv

Undersøkelsen: forstår du at HA/DR er en **avveining mellom konsistens, latency og datatap** — ikke "bare legg til en replica". Bra: active-passive med en standby. Utmerket: du oppgir RPO/RTO, sync-vs-async-implikasjoner, og split-brain-risikoen. Felle: å hevde at async gir null datatap, eller å anta at failover er umiddelbar og tapsfri.

## Avveininger og feilmoduser

- **Split-brain:** en nettverkspartisjon promoterer to primaries → divergent data. Bruk quorum, fencing, eller en witness-region.
- **Failback er vanskelig:** etter at den gamle primaryen kommer tilbake, er avstemming av divergente writes manuell og feilutsatt.
- **Kostnad:** ekte multi-region dobler omtrent infra og legger til cross-region egress-båndbreddregninger.
- **Utestet failover feiler:** DR som aldri øves vil ikke fungere i det ekte utfallet — kjør game-days.

Active-passive vs active-active

Sync vs async replikering

Failover, RPO og RTO

Intervjuperspektiv

Avveininger og feilmoduser

Relaterte spørsmål