आप HA और DR के लिए एक multi-region DB कैसे डिज़ाइन करते हैं?

Question

IT Interview Practice · Accepted Answer

database को regions में replicate करें और ज़रूरत के हिसाब से topology चुनें: सरलता और strong consistency के लिए **active-passive** (एक writer, एक warm standby जो failover पर संभालता है), या conflict resolution की कीमत पर low write latency के लिए **active-active** (कई writers) — फिर durability को latency के विरुद्ध trade करने के लिए **sync बनाम 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 बनाम active-active

**Active-passive** में एक primary writes संभालता है और standbys केवल read करते हैं; failure पर आप एक standby **promote** करते हैं। यह सरल है और write conflicts टालता है, पर passive capacity खाली बैठती है और 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 बनाम async replication

यह मुख्य durability/latency trade है। **Synchronous:** primary commit करने से पहले remote replica के acknowledge का इंतज़ार करता है — **RPO = 0** (failover पर कोई data loss नहीं) पर हर write एक cross-region round-trip latency (~दसियों ms) चुकाता है, और अगर replica unreachable है, writes अटक जाते हैं। **Asynchronous:** primary locally commit करता है और बाद में changes भेजता है — तेज़ writes, पर एक region loss अंतिम कुछ सेकंड खो सकता है (**RPO > 0**)। Cross-region sync अक्सर बहुत धीमा है, इसलिए कई async चलाते हैं और एक छोटा RPO स्वीकार करते हैं।

## Failover, RPO और RTO

- **RPO (Recovery Point Objective):** आप कितना data खो सकते हैं — sync बनाम async से सेट।
- **RTO (Recovery Time Objective):** आपके वापस आने तक कितनी देर — आप failure कितनी जल्दी detect करते और promote करते हैं इससे सेट।
- Failover = detect (health checks) → standby promote → traffic repoint (DNS/global LB)। इसे automate करें, पर **split-brain** (दोनों regions सोचें वे primary हैं) से एक quorum/fencing token से बचाव करें।

## इंटरव्यू का नज़रिया

परख: क्या आप समझते हैं HA/DR **consistency, latency, और data loss के बीच एक trade** है — केवल "एक replica जोड़ें" नहीं। अच्छा: एक standby के साथ active-passive। बढ़िया: आप RPO/RTO, sync-बनाम-async निहितार्थ, और split-brain जोखिम बताते हैं। जाल: दावा करना कि async zero data loss देता है, या मानना कि failover तुरंत और lossless है।

## ट्रेड-ऑफ़ और failure modes

- **Split-brain:** एक network partition दो primaries promote करता है → divergent data। quorum, fencing, या एक witness region इस्तेमाल करें।
- **Failback कठिन है:** पुराने primary के लौटने के बाद, divergent writes reconcile करना manual और error-prone है।
- **Cost:** सच्चा multi-region मोटे तौर पर infra दोगुना करता है और cross-region egress bandwidth bills जोड़ता है।
- **Untested failover fail होता है:** DR जिसे कभी drill नहीं किया वह असली outage में काम नहीं करेगा — game-days चलाएं।

Active-passive बनाम active-active

Sync बनाम async replication

Failover, RPO और RTO

इंटरव्यू का नज़रिया

ट्रेड-ऑफ़ और failure modes

संबंधित प्रश्न