Ta yaya za ka tsara multi-region DB ga HA da DR?

Question

IT Interview Practice · Accepted Answer

Replicate database a kan yankuna kuma ka zaɓi topology bisa buƙata: **active-passive** (writer ɗaya, warm standby da ke karɓa a failover) don sauƙi da strong consistency, ko **active-active** (writers da yawa) don low write latency da farashin conflict resolution — sannan ka zaɓi **sync vs async replication** don sulhu tsakanin durability da latency, kuma ka bayyana bayyanannun **RPO/RTO** targets da ke motsa 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** yana da primary ɗaya da ke sarrafa writes da standbys da ke read kawai; a gazawa kana **promote** standby. Mai sauƙi ne kuma yana guje wa write conflicts, amma passive capacity yana zaune babu aiki kuma failover yana da gibi. **Active-active** yana bar kowane yanki ya karɓi writes don local latency kuma babu failover promotion — amma yankuna biyu na iya edit same row a lokaci guda, don haka *dole* ka warware conflicts (last-write-wins, CRDTs, ko app-level merge). Yawancin tawagogi suna farawa da active-passive; active-active don global write latency da ba za ka iya biya in ba haka ba.

## Sync vs async replication

Wannan shi ne ainihin durability/latency trade. **Synchronous:** primary yana jira remote replica ya acknowledge kafin committing — **RPO = 0** (babu data loss a failover) amma kowane write yana biyan cross-region round-trip latency (kusan tens of ms), kuma idan replica ba mai isa ba, writes suna tsayawa. **Asynchronous:** primary yana commit locally kuma yana aika canje-canje daga baya — writes masu sauri, amma asarar yanki na iya rasa 'yan daƙiƙu na ƙarshe (**RPO > 0**). Cross-region sync sau da yawa mai jinkiri sosai, don haka da yawa suna gudanar da async kuma suna karɓar ƙaramin RPO.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** yawan data da za ka rasa — an saita da sync vs async.
- **RTO (Recovery Time Objective):** tsawon lokacin da za ka dawo — an saita da yadda za ka gano gazawa da sauri kuma ka promote.
- Failover = gano (health checks) → promote standby → repoint traffic (DNS/global LB). Automate shi, amma ka kare kanka daga **split-brain** (yankuna biyu suna tunanin su ne primary) da quorum/fencing token.

## Ra'ayin hira

Bincike: ko ka fahimci HA/DR **sulhu ne tsakanin consistency, latency, da data loss** — ba "ƙara replica kawai ba". Mai kyau: active-passive da standby. Mai kyau sosai: ka bayyana RPO/RTO, sync-vs-async implications, da split-brain risk. Tarko: da'awar async yana ba da zero data loss, ko ɗaukar failover nan take ne kuma lossless.

## Sulhu & hanyoyin gazawa

- **Split-brain:** network partition yana promote primaries biyu → divergent data. Yi amfani da quorum, fencing, ko witness region.
- **Failback yana da wuya:** bayan old primary ya dawo, sulhunta divergent writes na hannu ne kuma mai saurin kuskure.
- **Cost:** true multi-region kusan yana ninka infra kuma yana ƙara cross-region egress bandwidth bills.
- **Untested failover yana gaza:** DR da ba a taɓa drill ba ba zai yi aiki a ainihin outage ba — gudanar da game-days.

Active-passive vs active-active

Sync vs async replication

Failover, RPO & RTO

Ra'ayin hira

Sulhu & hanyoyin gazawa

Tambayoyi masu alaƙa