Hur designar du en multi-region-DB för HA och DR?

Question

IT Interview Practice · Accepted Answer

Replikera databasen över regioner och välj din topologi efter behov: **active-passive** (en skrivare, en warm standby som tar över vid failover) för enkelhet och stark konsistens, eller **active-active** (flera skrivare) för låg skrivlatens till priset av konfliktlösning — välj sedan **sync vs async replication** för att avväga hållbarhet mot latens, och definiera explicita **RPO/RTO**-mål som 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 en primary som hanterar skrivningar och standbys som bara läser; vid fel **befordrar** du en standby. Det är enkelt och undviker skrivkonflikter, men den passiva kapaciteten står oanvänd och failover har ett glapp. **Active-active** låter varje region acceptera skrivningar för lokal latens och ingen failover-befordran — men två regioner kan editera samma rad samtidigt, så du *måste* lösa konflikter (last-write-wins, CRDTs, eller merge på app-nivå). De flesta team börjar active-passive; active-active är för global skrivlatens du genuint inte kan möta på annat sätt.

## Sync vs async replication

Detta är den centrala hållbarhet/latens-avvägningen. **Synkron:** primary väntar på att den fjärran replican ackar innan commit — **RPO = 0** (ingen dataförlust vid failover) men varje skrivning betalar cross-region round-trip-latens (~tiotals ms), och om replican är onåbar stannar skrivningar. **Asynkron:** primary committar lokalt och skeppar ändringar efteråt — snabba skrivningar, men en regionförlust kan förlora de senaste sekunderna (**RPO > 0**). Cross-region sync är ofta för långsam, så många kör async och accepterar en liten RPO.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** hur mycket data du kan förlora — satt av sync vs async.
- **RTO (Recovery Time Objective):** hur länge tills du är tillbaka — satt av hur snabbt du upptäcker fel och befordrar.
- Failover = upptäck (health checks) → befordra standby → dirigera om trafik (DNS/global LB). Automatisera det, men skydda mot **split-brain** (båda regionerna tror de är primary) med ett quorum/fencing token.

## Intervjuperspektiv

Undersökningen: förstår du att HA/DR är en **avvägning mellan konsistens, latens och dataförlust** — inte "bara lägg till en replica". Bra: active-passive med en standby. Utmärkt: du anger RPO/RTO, sync-vs-async-implikationer, och split-brain-risken. Fälla: att hävda att async ger noll dataförlust, eller att anta att failover är omedelbar och förlustfri.

## Avvägningar & felmoder

- **Split-brain:** en nätverkspartition befordrar två primaries → divergent data. Använd quorum, fencing eller en witness-region.
- **Failback är svårt:** efter att den gamla primary:n återvänder är avstämning av divergenta skrivningar manuell och felbenägen.
- **Kostnad:** äkta multi-region ungefär fördubblar infra och lägger till cross-region egress-bandbreddsräkningar.
- **Otestad failover fallerar:** DR som aldrig övats fungerar inte i det verkliga avbrottet — kör game-days.

Active-passive vs active-active

Sync vs async replication

Failover, RPO & RTO

Intervjuperspektiv

Avvägningar & felmoder

Relaterade frågor