10TB database کو zero downtime کے ساتھ migrate کریں: منصوبہ کیا ہے؟

Question

IT Interview Practice · Accepted Answer

**پرانے اور نئے دونوں کو dual-write کریں، تاریخ کو background میں backfill کریں، آخری حصے کو پکڑنے کے لیے CDC استعمال کریں، shadow reads سے verify کریں، پھر reads کو atomically flip کریں — ہر قدم پر ایک rollback path کے ساتھ۔** آپ کبھی app کو نیچے نہیں کرتے؛ آپ دونوں databases کو متوازی چلاتے ہیں جب تک نیا واضح طور پر یکساں ثابت نہ ہو جائے، پھر cut over کرتے ہیں۔

## فن تعمیر

```text
        ┌── write ──▶ OLD DB (source of truth) ──CDC (Debezium)──┐
 App ───┤                                                        ▼
        └── write ──▶ NEW DB ◀──── backfill job (historical rows)
                        │
   shadow reads (compare OLD vs NEW) ─▶ diff metrics ─▶ atomic cutover ─▶ NEW is truth
                                                          (flip flag; rollback = flip back)
```

## یہ کیسے کام کرتا ہے

1. **Dual-write۔** app ہر تبدیلی OLD اور NEW دونوں کو لکھتی ہے۔ نئی rows اب سے sync رہتی ہیں؛ صرف تاریخ غائب ہے۔
2. **Backfill۔** ایک background job تاریخی rows کو batches میں copy کرتا ہے (prod کی حفاظت کے لیے throttled)۔ `INSERT ... ON CONFLICT DO NOTHING` استعمال کریں تاکہ یہ idempotent اور دوبارہ چلانے کے لیے محفوظ ہو۔
3. **CDC catch-up۔** Dual-write switch-on کے دوران لکھی گئی rows چھوڑ سکتا ہے۔ OLD DB کے WAL/binlog کو stream کرتا **Debezium** ہر تبدیلی replay کرتا ہے، اُس gap کو بند کرتے ہوئے جو backfill نہیں کر سکتا۔
4. **Shadow reads۔** OLD کے ساتھ متوازی NEW سے پڑھیں، **نتائج کا موازنہ کریں**، اور ایک diff metric خارج کریں۔ وقت کے ساتھ صفر diffs = NEW قابلِ اعتماد ہے۔
5. **Cutover۔** ایک feature flag flip کریں تاکہ reads (پھر writes) NEW کی طرف جائیں۔ یہ ایک config تبدیلی ہے، deploy نہیں — فوری، اور **واپس flip کر کے reversible**۔

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

انٹرویو لینے والا چاہتا ہے کہ **آپ کوئی data loss اور کوئی downtime کیسے ضمانت دیتے ہیں**، اور کیا آپ کے پاس ایک **rollback** ہے۔ اچھے جواب dual-write کا ذکر کرتے ہیں؛ عمدہ جواب **race window پکڑنے کے لیے CDC**، **بھروسہ کرنے سے پہلے verify کرنے کے لیے shadow reads**، اور ایک **atomic، reversible flag flip** شامل کرتے ہیں۔ کلاسک جال "backfill پھر switch" بغیر verification کے ہے — آپ mismatch اُس وقت دریافت کرتے ہیں جب users اسے hit کر لیتے ہیں، بغیر واپسی کے راستے کے۔

## توازن اور ناکامی

- **Dual-write مطابقت۔** اگر NEW write ناکام ہو مگر OLD کامیاب، تو وہ diverge کر جاتی ہیں۔ OLD کو authoritative بنائیں اور CDC کو NEW مرمت کرنے دیں، بجائے صارف کی request ناکام کرنے کے۔
- **لاگت اور پیچیدگی۔** دو databases + CDC + backfill چلانا مہنگا اور operationally بھاری ہے — صرف بڑے، critical stores کے لیے جائز۔
- **Migration کے دوران Schema تبدیلیاں** خطرہ کئی گنا کر دیتی ہیں؛ cutover تک schema freeze کریں۔
- **Backfill load۔** ایک unthrottled backfill prod I/O کو saturate کر کے outage پیدا کر سکتا ہے — مقصد کے برعکس؛ batch اور rate-limit کریں۔
- **Rollback window۔** cutover کے بعد دنوں تک dual-writing (اب NEW→OLD) جاری رکھیں تاکہ اگر کوئی latent bug سامنے آئے تو آپ واپس flip کر سکیں۔ تب ہی OLD کو decommission کریں۔
- **کب نہیں:** ایک maintenance window والا چھوٹا DB کو اس کی ضرورت نہیں — ایک 30 منٹ کا `pg_dump`/restore ایک CDC pipeline سے سادہ اور محفوظ تر ہے۔

فن تعمیر

یہ کیسے کام کرتا ہے

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

توازن اور ناکامی

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