તમે HA અને DR માટે multi-region DB કેવી રીતે ડિઝાઇન કરશો?

Question

IT Interview Practice · Accepted Answer

database ને regions પર replicate કરો અને જરૂર પ્રમાણે તમારી topology પસંદ કરો: સરળતા અને strong consistency માટે **active-passive** (એક writer, એક warm standby જે failover પર take over કરે), અથવા conflict resolution ના cost પર low write latency માટે **active-active** (multiple writers) — પછી durability ને latency સામે trade કરવા **sync vs async replication** પસંદ કરો, અને failover ને ચલાવતા સ્પષ્ટ **RPO/RTO** targets define કરો.

```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** પાસે writes સંભાળતો એક primary અને માત્ર read કરતા standbys છે; failure પર તમે એક standby ને **promote** કરો છો. તે સરળ છે અને write conflicts ટાળે છે, પણ passive capacity idle બેસે છે અને failover માં gap છે. **Active-active** દરેક region ને local latency માટે writes સ્વીકારવા દે છે અને કોઈ failover promotion નહીં — પણ બે regions એ જ row ને concurrently edit કરી શકે, તેથી તમારે conflicts resolve કરવા *જ પડે* (last-write-wins, CRDTs, અથવા app-level merge). મોટાભાગની teams active-passive થી શરૂ કરે છે; active-active એ global write latency માટે છે જે તમે ખરેખર બીજી રીતે મેળવી ન શકો.

## Sync vs async replication

આ core durability/latency trade છે. **Synchronous:** primary commit કરતાં પહેલાં remote replica ના acknowledge ની રાહ જુએ છે — **RPO = 0** (failover પર no data loss) પણ દરેક write cross-region round-trip latency (~દસ ms) ચૂકવે છે, અને જો replica unreachable હોય, writes stall થાય છે. **Asynchronous:** primary locally commit કરે છે અને changes પછી ship કરે છે — ઝડપી writes, પણ region loss છેલ્લી થોડી સેકન્ડ્સ ગુમાવી શકે (**RPO > 0**). Cross-region sync ઘણી વાર ખૂબ ધીમું છે, તેથી ઘણા async ચલાવે છે અને નાનું RPO સ્વીકારે છે.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** તમે કેટલો data ગુમાવી શકો — sync vs async વડે set.
- **RTO (Recovery Time Objective):** પાછા આવવામાં કેટલો સમય — તમે failure કેટલી ઝડપથી detect અને promote કરો છો તેના વડે set.
- Failover = detect (health checks) → standby promote → traffic repoint (DNS/global LB). તેને automate કરો, પણ quorum/fencing token વડે **split-brain** (બંને regions પોતાને primary માને) સામે રક્ષણ કરો.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Probe: શું તમે સમજો છો કે HA/DR એ **consistency, latency, અને data loss વચ્ચેનો trade** છે — "just add a replica" નહીં. Good: standby સાથે active-passive. Great: તમે RPO/RTO, sync-vs-async implications, અને split-brain risk જણાવો છો. Trap: દાવો કરવો કે async zero data loss આપે છે, અથવા ધારવું કે failover instant અને lossless છે.

## Trade-offs અને failure modes

- **Split-brain:** network partition બે primaries promote કરે → divergent data. quorum, fencing, અથવા witness region વાપરો.
- **Failback મુશ્કેલ છે:** જૂનો primary પાછો આવ્યા પછી, divergent writes reconcile કરવું manual અને error-prone છે.
- **Cost:** true multi-region લગભગ infra double કરે છે અને cross-region egress bandwidth bills ઉમેરે છે.
- **Untested failover fail થાય છે:** જે DR ક્યારેય drill ન થયું તે real outage માં કામ નહીં કરે — game-days ચલાવો.

Active-passive vs active-active

Sync vs async replication

Failover, RPO & RTO

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure modes

સંબંધિત પ્રશ્નો