Kako dizajnirati multi-region bazu podataka za HA i DR?

Question

IT Interview Practice · Accepted Answer

Replicirajte bazu preko regija i odaberite topologiju prema potrebi: **active-passive** (jedan writer, warm standby koji preuzima pri failoveru) za jednostavnost i jaku konzistentnost, ili **active-active** (više writera) za nisku latenciju upisa uz cijenu rješavanja konflikata — zatim odaberite **sync vs async replikaciju** da odvagnete trajnost naspram latencije i definirajte eksplicitne **RPO/RTO** ciljeve koji vode 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** ima jedan primary koji obrađuje upise i standbyje koji samo čitaju; pri neuspjehu **promovirate** standby. Jednostavno je i izbjegava konflikte upisa, ali pasivni kapacitet miruje i failover ima jaz. **Active-active** dopušta svakoj regiji prihvaćanje upisa za lokalnu latenciju i bez failover promocije — ali dvije regije mogu istovremeno urediti isti redak, pa *morate* rješavati konflikte (last-write-wins, CRDT-ovi ili merge na razini aplikacije). Većina timova počinje s active-passive; active-active je za globalnu latenciju upisa koju stvarno ne možete drukčije postići.

## Sync vs async replikacija

Ovo je ključni kompromis trajnost/latencija. **Sinkrono:** primary čeka da udaljena replika potvrdi prije commitanja — **RPO = 0** (bez gubitka podataka pri failoveru) ali svaki upis plaća cross-region round-trip latenciju (~desetci ms), a ako je replika nedostupna, upisi se zaustavljaju. **Asinkrono:** primary commita lokalno i šalje promjene poslije — brzi upisi, ali gubitak regije može izgubiti zadnjih nekoliko sekundi (**RPO > 0**). Cross-region sync je često prespor, pa mnogi pokreću async i prihvaćaju mali RPO.

## Failover, RPO i RTO

- **RPO (Recovery Point Objective):** koliko podataka možete izgubiti — postavljeno sync vs async.
- **RTO (Recovery Time Objective):** koliko dugo dok se ne vratite — postavljeno time koliko brzo otkrijete neuspjeh i promovirate.
- Failover = otkrivanje (health checkovi) → promocija standbyja → preusmjeravanje prometa (DNS/globalni LB). Automatizirajte to, ali čuvajte se od **split-braina** (obje regije misle da su primary) kvorumom/fencing tokenom.

## Perspektiva intervjua

Ispituje se: razumijete li da je HA/DR **kompromis između konzistentnosti, latencije i gubitka podataka** — ne "samo dodaj repliku". Dobro: active-passive sa standbyjem. Odlično: navodite RPO/RTO, sync-vs-async implikacije i rizik split-braina. Zamka: tvrditi da async daje nula gubitka podataka, ili pretpostaviti da je failover trenutan i bez gubitka.

## Kompromisi i načini otkazivanja

- **Split-brain:** mrežna particija promovira dva primaryja → razilazeći podaci. Koristite kvorum, fencing ili witness regiju.
- **Failback je težak:** nakon što se stari primary vrati, usklađivanje razilazećih upisa je ručno i sklono pogreškama.
- **Trošak:** pravi multi-region otprilike udvostručuje infrastrukturu i dodaje račune za cross-region egress bandwidth.
- **Netestiran failover otkazuje:** DR koji se nikad ne vježba neće raditi u stvarnom prekidu — pokrećite game-daysove.

Active-passive vs active-active

Sync vs async replikacija

Failover, RPO i RTO

Perspektiva intervjua

Kompromisi i načini otkazivanja

Povezana pitanja