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-এর মূল্যে low write latency-এর জন্য **active-active** (একাধিক writer) — তারপর latency-এর বিপরীতে durability 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 কেবল read করে; failure-এ আপনি একটি standby **promote** করেন। এটি সরল এবং write conflict এড়ায়, কিন্তু passive capacity অলস বসে থাকে এবং failover-এ একটি gap থাকে। **Active-active** প্রতিটি region-কে local latency-এর জন্য write গ্রহণ করতে দেয় এবং কোনো failover promotion নেই — কিন্তু দুটি region একসাথে একই row edit করতে পারে, তাই আপনাকে *অবশ্যই* conflict resolve করতে হবে (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 = ০** (failover-এ কোনো data loss নেই) কিন্তু প্রতিটি write cross-region round-trip latency (~দশ ms) দেয়, এবং replica unreachable হলে write আটকে যায়। **Asynchronous:** primary locally commit করে এবং পরে পরিবর্তন পাঠায় — দ্রুত write, কিন্তু একটি region loss শেষ কয়েক সেকেন্ড হারাতে পারে (**RPO > ০**)। Cross-region sync প্রায়ই খুব ধীর, তাই অনেকে async চালায় এবং একটি ছোট RPO মেনে নেয়।

## Failover, RPO ও RTO

- **RPO (Recovery Point Objective):** আপনি কত data হারাতে পারেন — sync বনাম async দ্বারা নির্ধারিত।
- **RTO (Recovery Time Objective):** আপনি কতক্ষণে ফিরবেন — আপনি কত দ্রুত failure শনাক্ত করে promote করেন তা দ্বারা নির্ধারিত।
- Failover = detect (health check) → standby promote → traffic repoint (DNS/global LB)। এটি স্বয়ংক্রিয় করুন, কিন্তু একটি quorum/fencing token দিয়ে **split-brain** (উভয় region নিজেকে primary ভাবে)-এর বিরুদ্ধে সুরক্ষা দিন।

## ইন্টারভিউ দৃষ্টিভঙ্গি

যাচাই: আপনি বোঝেন কিনা যে HA/DR হলো **consistency, latency ও data loss-এর মধ্যে একটি trade** — "শুধু একটি replica যোগ করুন" নয়। ভালো: একটি standby সহ active-passive। দারুণ: আপনি RPO/RTO, sync-বনাম-async প্রভাব, এবং split-brain ঝুঁকি বলেন। ফাঁদ: async শূন্য data loss দেয় দাবি করা, বা failover তাৎক্ষণিক ও lossless ধরে নেওয়া।

## ট্রেড-অফ ও ব্যর্থতার ধরন

- **Split-brain:** একটি network partition দুটি primary promote করে → divergent data। quorum, fencing, বা একটি witness region ব্যবহার করুন।
- **Failback কঠিন:** পুরনো primary ফিরে আসার পর, divergent write reconcile করা manual ও error-prone।
- **খরচ:** সত্যিকারের multi-region মোটামুটি infra দ্বিগুণ করে এবং cross-region egress bandwidth bill যোগ করে।
- **Untested failover ব্যর্থ হয়:** যে DR কখনও drill করা হয়নি তা বাস্তব outage-এ কাজ করবে না — game-day চালান।

Active-passive বনাম active-active

Sync বনাম async replication

Failover, RPO ও RTO

ইন্টারভিউ দৃষ্টিভঙ্গি

ট্রেড-অফ ও ব্যর্থতার ধরন

সম্পর্কিত প্রশ্ন