HA మరియు DR కోసం ఒక multi-region DB ను మీరు ఎలా design చేస్తారు?

Question

IT Interview Practice · Accepted Answer

database ను regions అంతటా replicate చేసి అవసరాన్ని బట్టి మీ topology ను ఎంచుకోండి: సరళత మరియు strong consistency కోసం **active-passive** (ఒక writer, failover పై అందుకునే ఒక warm standby), లేదా conflict resolution ఖర్చుతో low write latency కోసం **active-active** (అనేక writers) — తర్వాత latency కి వ్యతిరేకంగా durability ను trade చేయడానికి **sync vs async replication** ను ఎంచుకుని, failover ను driving చేసే స్పష్టమైన **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 ను handle చేసే ఒక 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 పై data loss లేదు) కానీ ప్రతి write cross-region round-trip latency (~పదుల ms) ను pay చేస్తుంది, మరియు replica unreachable అయితే, writes నిలిచిపోతాయి. **Asynchronous:** primary local గా commit చేసి తర్వాత మార్పులను ship చేస్తుంది — fast writes, కానీ ఒక region loss చివరి కొన్ని seconds ను కోల్పోవచ్చు (**RPO > 0**). Cross-region sync తరచుగా చాలా నెమ్మది, కాబట్టి చాలామంది async run చేసి ఒక చిన్న 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 అనేది "just add a replica" కాదు, **consistency, latency, మరియు data loss మధ్య ఒక trade** అని మీకు అర్థమైందా. మంచిది: ఒక standby తో active-passive. గొప్పది: మీరు RPO/RTO, sync-vs-async implications, మరియు split-brain risk ను పేర్కొంటారు. ఉచ్చు: async zero data loss ను ఇస్తుందని దావా వేయడం, లేదా failover instant మరియు 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 fail అవుతుంది:** ఎప్పుడూ drill చేయని DR నిజమైన outage లో పనిచేయదు — game-days run చేయండి.

Active-passive vs active-active

Sync vs async replication

Failover, RPO & RTO

ఇంటర్వ్యూ దృక్కోణం

ట్రేడ్-ఆఫ్‌లు & వైఫల్య మోడ్‌లు

సంబంధిత ప్రశ్నలు