Cum proiectezi un DB multi-region pentru HA și DR?

Question

IT Interview Practice · Accepted Answer

Replică baza de date pe mai multe regiuni și alege topologia după nevoie: **active-passive** (un writer, un warm standby care preia la failover) pentru simplitate și consistență puternică, sau **active-active** (mai mulți writeri) pentru latență mică de scriere cu costul rezolvării conflictelor — apoi alege **sync vs async replication** pentru a compensa durabilitatea cu latența și definește ținte **RPO/RTO** explicite care conduc failover-ul.

```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** are un primary care gestionează scrierile și standby-uri care doar citesc; la eșec **promovezi** un standby. Este simplu și evită conflictele de scriere, dar capacitatea pasivă stă inactivă, iar failover-ul are un gol. **Active-active** lasă fiecare regiune să accepte scrieri pentru latență locală și fără promovare la failover — dar două regiuni pot edita concurent același rând, deci *trebuie* să rezolvi conflictele (last-write-wins, CRDT-uri sau merge la nivel de aplicație). Majoritatea echipelor încep cu active-passive; active-active este pentru latență de scriere globală pe care chiar nu o poți atinge altfel.

## Sync vs async replication

Acesta este compromisul central durabilitate/latență. **Sincron:** primary-ul așteaptă ca replica remote să confirme înainte de a face commit — **RPO = 0** (fără pierdere de date la failover), dar fiecare scriere plătește latența round-trip cross-region (~zeci de ms), iar dacă replica este inaccesibilă, scrierile se blochează. **Asincron:** primary-ul face commit local și trimite modificările după — scrieri rapide, dar o pierdere de regiune poate pierde ultimele câteva secunde (**RPO > 0**). Sync-ul cross-region este adesea prea lent, deci mulți rulează async și acceptă un RPO mic.

## Failover, RPO și RTO

- **RPO (Recovery Point Objective):** câte date poți pierde — stabilit de sync vs async.
- **RTO (Recovery Time Objective):** cât până ești înapoi — stabilit de cât de repede detectezi eșecul și promovezi.
- Failover = detectează (health checks) → promovează standby → repointează traficul (DNS/global LB). Automatizează-l, dar protejează-te împotriva **split-brain** (ambele regiuni cred că sunt primary) cu un token de quorum/fencing.

## Perspectiva de interviu

Sondajul: înțelegi că HA/DR este un **compromis între consistență, latență și pierdere de date** — nu "pur și simplu adaugă o replică". Bine: active-passive cu un standby. Excelent: enunți RPO/RTO, implicațiile sync-vs-async și riscul de split-brain. Capcană: a susține că async oferă zero pierdere de date, sau a presupune că failover-ul este instantaneu și fără pierderi.

## Compromisuri și moduri de eșec

- **Split-brain:** o partiție de rețea promovează două primary-uri → date divergente. Folosește quorum, fencing sau o regiune-martor.
- **Failback-ul este greu:** după ce vechiul primary revine, reconcilierea scrierilor divergente este manuală și predispusă la erori.
- **Cost:** multi-region real aproape dublează infrastructura și adaugă facturi de bandă de egress cross-region.
- **Failover-ul netestat eșuează:** un DR niciodată exersat nu va funcționa în căderea reală — rulează game-days.

Active-passive vs active-active

Sync vs async replication

Failover, RPO și RTO

Perspectiva de interviu

Compromisuri și moduri de eșec

Întrebări conexe