آپ HA اور DR کے لیے ایک multi-region DB کیسے ڈیزائن کرتے ہیں؟

Question

IT Interview Practice · Accepted Answer

database کو regions میں replicate کریں اور اپنی topology ضرورت سے چنیں: سادگی اور مضبوط مطابقت کے لیے **active-passive** (ایک writer، ایک warm standby جو failover پر سنبھال لے)، یا conflict resolution کی قیمت پر کم write latency کے لیے **active-active** (کئی writers) — پھر durability کو latency کے مقابلے میں طے کرنے کے لیے **sync بمقابلہ async replication** چنیں، اور failover چلانے والے واضح **RPO/RTO** اہداف مقرر کریں۔

```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 صرف پڑھتے ہیں؛ ناکامی پر آپ ایک standby کو **promote** کرتے ہیں۔ یہ سادہ ہے اور write conflicts سے بچتا ہے، مگر passive capacity بیکار بیٹھی رہتی ہے اور failover میں ایک gap ہوتا ہے۔ **Active-active** ہر region کو مقامی latency کے لیے writes قبول کرنے دیتا ہے اور کوئی failover promotion نہیں — مگر دو regions ایک ہی row کو بیک وقت edit کر سکتے ہیں، لہٰذا آپ کو conflicts *ضرور* حل کرنے ہوں گے (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 ناقابلِ رسائی ہو، تو writes رک جاتی ہیں۔ **Asynchronous:** primary مقامی طور پر commit کرتا ہے اور تبدیلیاں بعد میں بھیجتا ہے — تیز writes، مگر ایک region کا نقصان آخری چند سیکنڈ کھو سکتا ہے (**RPO > 0**)۔ Cross-region sync اکثر بہت سست ہوتا ہے، لہٰذا بہت سے async چلاتے ہیں اور ایک چھوٹا RPO قبول کرتے ہیں۔

## Failover، RPO اور RTO

- **RPO (Recovery Point Objective):** آپ کتنا ڈیٹا کھو سکتے ہیں — sync بمقابلہ async سے طے۔
- **RTO (Recovery Time Objective):** آپ کتنی دیر میں واپس آتے ہیں — آپ ناکامی کتنی تیزی سے detect اور promote کرتے ہیں اس سے طے۔
- Failover = detect (health checks) → standby promote کریں → traffic repoint کریں (DNS/global LB)۔ اسے خودکار کریں، مگر ایک quorum/fencing token سے **split-brain** (دونوں regions سمجھیں کہ وہ primary ہیں) کے خلاف حفاظت کریں۔

## انٹرویو کا نقطۂ نظر

جانچ: کیا آپ سمجھتے ہیں کہ HA/DR **consistency، latency، اور data loss کے درمیان ایک trade** ہے — نہ کہ "بس ایک replica شامل کرو"۔ اچھا: ایک standby کے ساتھ active-passive۔ عمدہ: آپ RPO/RTO، sync-vs-async مضمرات، اور split-brain خطرہ بیان کرتے ہیں۔ جال: دعویٰ کرنا کہ async صفر data loss دیتا ہے، یا فرض کرنا کہ failover فوری اور بے نقصان ہے۔

## توازن اور ناکامی کے طریقے

- **Split-brain:** ایک network partition دو primaries کو promote کرتا ہے → divergent data۔ quorum، fencing، یا ایک witness region استعمال کریں۔
- **Failback مشکل ہے:** پرانے primary کی واپسی کے بعد، divergent writes کو reconcile کرنا manual اور error-prone ہے۔
- **لاگت:** حقیقی multi-region تقریباً infra دوگنا کرتا ہے اور cross-region egress bandwidth bills بڑھاتا ہے۔
- **Untested failover ناکام ہوتا ہے:** جو DR کبھی drill نہیں کیا گیا وہ اصل outage میں کام نہیں کرے گا — game-days چلائیں۔

Active-passive بمقابلہ active-active

Sync بمقابلہ async replication

Failover، RPO اور RTO

انٹرویو کا نقطۂ نظر

توازن اور ناکامی کے طریقے

متعلقہ سوالات