ਤੁਸੀਂ HA ਅਤੇ DR ਲਈ ਇੱਕ multi-region DB ਕਿਵੇਂ design ਕਰਦੇ ਹੋ?

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 vs 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 vs 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 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) ਚੁਕਾਉਂਦਾ ਹੈ, ਅਤੇ ਜੇ 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 vs async ਦੁਆਰਾ set।
- **RTO (Recovery Time Objective):** ਤੁਹਾਨੂੰ ਵਾਪਸ ਆਉਣ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ — ਇਸ ਗੱਲ ਦੁਆਰਾ set ਕਿ ਤੁਸੀਂ ਕਿੰਨੀ ਜਲਦੀ 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-vs-async implications, ਅਤੇ split-brain risk ਦੱਸਦੇ ਹੋ। ਫੰਦਾ: ਇਹ ਦਾਅਵਾ ਕਰਨਾ ਕਿ async zero 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 fails:** ਓਹ DR ਜੋ ਕਦੇ drill ਨਹੀਂ ਹੋਇਆ ਅਸਲੀ outage ਵਿੱਚ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ — game-days ਚਲਾਓ।

Active-passive vs active-active

Sync vs async replication

Failover, RPO ਅਤੇ RTO

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

ਸੰਬੰਧਿਤ ਸਵਾਲ