HA र DR का लागि multi-region DB कसरी डिजाइन गर्नुहुन्छ?

Question

IT Interview Practice · Accepted Answer

database लाई region हरूमा replicate गर्नुहोस् र आवश्यकता अनुसार topology छान्नुहोस्: सरलता र strong consistency का लागि **active-passive** (एउटा writer, एउटा warm standby जसले failover मा सम्हाल्छ), वा conflict resolution को लागतमा कम write latency का लागि **active-active** (धेरै writer) — अनि durability लाई latency विरुद्ध trade गर्न **sync बनाम async replication** छान्नुहोस्, र failover चलाउने स्पष्ट **RPO/RTO** target परिभाषित गर्नुहोस्।

```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 ले write सम्हाल्छ र standby ले मात्र पढ्छ; failure मा तपाईं standby **promote** गर्नुहुन्छ। यो सरल छ र write conflict बचाउँछ, तर passive क्षमता निष्क्रिय बस्छ र failover मा अन्तर हुन्छ। **Active-active** ले प्रत्येक region लाई local latency का लागि write स्वीकार्न र failover promotion बिना बनाउँछ — तर दुई region ले एउटै row concurrently सम्पादन गर्न सक्छन्, त्यसैले तपाईंले conflict *हल गर्नैपर्छ* (last-write-wins, CRDT, वा app-level merge)। धेरै team active-passive बाट सुरु गर्छन्; active-active तपाईंले साँच्चै अन्यथा पूरा गर्न नसक्ने global write latency का लागि हो।

## Sync बनाम async replication

यो मुख्य durability/latency trade हो। **Synchronous:** primary ले commit गर्नुअघि remote replica को acknowledge पर्खन्छ — **RPO = 0** (failover मा data हानि छैन) तर हरेक write ले cross-region round-trip latency (~दसौं ms) तिर्छ, र replica पुग्न नसके, write अड्किन्छन्। **Asynchronous:** primary local commit गर्छ र पछि change पठाउँछ — छिटो write, तर region हानि ले अन्तिम केही second गुमाउन सक्छ (**RPO > 0**)। Cross-region sync प्रायः धेरै ढिलो हुन्छ, त्यसैले धेरैले async चलाउँछन् र सानो RPO स्वीकार्छन्।

## Failover, RPO र RTO

- **RPO (Recovery Point Objective):** तपाईं कति data गुमाउन सक्नुहुन्छ — sync बनाम async ले सेट गर्छ।
- **RTO (Recovery Time Objective):** तपाईं फर्कन कति समय — तपाईं failure कति छिटो पत्ता लगाउनुहुन्छ र promote गर्नुहुन्छ भन्नाले सेट गर्छ।
- Failover = पत्ता लगाउ (health check) → standby promote → traffic repoint (DNS/global LB)। यसलाई automate गर्नुहोस्, तर quorum/fencing token सँग **split-brain** (दुवै region आफूलाई primary सम्झन्छन्) बाट जोगाउनुहोस्।

## अन्तर्वार्ता दृष्टिकोण

probe: तपाईं HA/DR लाई "बस एउटा replica थप" होइन, **consistency, latency, र data हानि बीचको trade** हो भनेर बुझ्नुहुन्छ कि। राम्रो: standby सहित active-passive। उत्कृष्ट: तपाईं RPO/RTO, sync-बनाम-async निहितार्थ, र split-brain जोखिम बताउनुहुन्छ। जाल: async ले शून्य data हानि दिन्छ भन्नु, वा failover तत्काल र lossless हुन्छ भनेर मान्नु।

## ट्रेड-अफ र failure mode

- **Split-brain:** network partition ले दुई primary promote गर्छ → विचलित data। quorum, fencing, वा witness region प्रयोग गर्नुहोस्।
- **Failback गाह्रो छ:** पुरानो primary फर्केपछि, विचलित write reconcile गर्नु manual र त्रुटिपूर्ण छ।
- **लागत:** साँचो multi-region ले infra लगभग दोब्बर पार्छ र cross-region egress bandwidth bill थप्छ।
- **Untested failover fail हुन्छ:** कहिल्यै drill नगरिएको DR वास्तविक outage मा काम गर्दैन — game-day चलाउनुहोस्।

Active-passive बनाम active-active

Sync बनाम async replication

Failover, RPO र RTO

अन्तर्वार्ता दृष्टिकोण

ट्रेड-अफ र failure mode

सम्बन्धित प्रश्नहरू