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 च्या किंमतीवर कमी write latency साठी **active-active** (अनेक writers) — नंतर durability ला latency विरुद्ध trade करण्यासाठी **sync vs async replication** निवडा आणि failover चालवणारे explicit **RPO/RTO** targets परिभाषित करा.

```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** मध्ये एक primary writes हाताळतो आणि standbys फक्त वाचतात; अपयशावर तुम्ही एक 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 vs async replication

ही मुख्य durability/latency तडजोड आहे. **Synchronous:** primary commit करण्याआधी remote replica च्या acknowledge ची वाट पाहतो — **RPO = 0** (failover वर data loss नाही) पण प्रत्येक write cross-region round-trip latency (~दहा ms) मोजते, आणि replica पोहोचता येत नसल्यास writes थांबतात. **Asynchronous:** primary locally commit करतो आणि नंतर बदल पाठवतो — जलद writes, पण एक region loss शेवटचे काही सेकंद गमावू शकतो (**RPO > 0**). Cross-region sync अनेकदा खूप slow असते, म्हणून अनेक async चालवतात आणि एक लहान RPO स्वीकारतात.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** तुम्ही किती data गमावू शकता — sync vs async ने सेट.
- **RTO (Recovery Time Objective):** तुम्ही परत येईपर्यंत किती वेळ — तुम्ही अपयश किती लवकर detect करता आणि promote करता याने सेट.
- Failover = detect (health checks) → standby promote → traffic repoint (DNS/global LB). ते automate करा, पण एका quorum/fencing token ने **split-brain** (दोन्ही regions स्वतःला primary मानतात) पासून रक्षण करा.

## मुलाखतीचा दृष्टिकोन

तपासणी: तुम्हाला समजते का की HA/DR ही **consistency, latency, आणि data loss यांच्यातील एक तडजोड** आहे — "फक्त एक replica जोडा" नाही. चांगले: standby सह active-passive. उत्तम: तुम्ही RPO/RTO, sync-vs-async परिणाम, आणि split-brain धोका मांडता. सापळा: async शून्य data loss देते असा दावा करणे, किंवा failover तत्काळ आणि lossless आहे असे गृहीत धरणे.

## तडजोडी आणि अपयश

- **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 अपयशी होते:** कधीही drill न केलेले DR खऱ्या outage मध्ये चालणार नाही — game-days चालवा.

Active-passive vs active-active

Sync vs async replication

Failover, RPO & RTO

मुलाखतीचा दृष्टिकोन

तडजोडी आणि अपयश

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