zero downtime-এ একটি ১০TB database migrate করুন: পরিকল্পনা কী?

Question

IT Interview Practice · Accepted Answer

**পুরনো ও নতুন-এ dual-write করুন, background-এ history backfill করুন, tail catch up করতে CDC ব্যবহার করুন, shadow read দিয়ে verify করুন, তারপর read atomically flip করুন — প্রতিটি ধাপে একটি rollback path সহ।** আপনি কখনও app down করেন না; আপনি দুটি database সমান্তরালে চালান যতক্ষণ না নতুনটি প্রমাণযোগ্যভাবে অভিন্ন, তারপর 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)
```

## কীভাবে কাজ করে

১. **Dual-write.** app প্রতিটি পরিবর্তন OLD ও NEW উভয়ে লেখে। নতুন row এখন থেকে sync-এ থাকে; কেবল history অনুপস্থিত।
২. **Backfill.** একটি background job historical row batch-এ copy করে (prod রক্ষায় throttled)। `INSERT ... ON CONFLICT DO NOTHING` ব্যবহার করুন যাতে এটি idempotent এবং পুনরায় চালানো নিরাপদ।
৩. **CDC catch-up.** Dual-write switch-on-এর সময় লেখা row মিস করতে পারে। **Debezium** OLD DB-এর WAL/binlog stream করে প্রতিটি পরিবর্তন replay করে, backfill যে gap পারে না তা বন্ধ করে।
৪. **Shadow read.** OLD-এর সমান্তরালে NEW থেকে পড়ুন, **ফলাফল তুলনা করুন**, এবং একটি diff metric নির্গত করুন। সময়ের সাথে শূন্য diff = NEW বিশ্বাসযোগ্য।
৫. **Cutover.** একটি feature flag flip করুন যাতে read (তারপর write) NEW-তে যায়। এটি একটি config পরিবর্তন, একটি deploy নয় — তাৎক্ষণিক, এবং **flip back করে reversible**।

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

ইন্টারভিউয়ার চান **আপনি কীভাবে কোনো data loss ও কোনো downtime নিশ্চিত করেন**, এবং আপনার একটি **rollback** আছে কিনা। ভালো উত্তর dual-write উল্লেখ করে; দারুণ উত্তর যোগ করে **race window ধরতে CDC**, **বিশ্বাস করার আগে verify করতে shadow read**, এবং একটি **atomic, reversible flag flip**। ক্লাসিক ফাঁদ হলো verification ছাড়া "backfill তারপর switch" — আপনি mismatch আবিষ্কার করেন ইউজার আঘাত করার পর, ফিরে যাওয়ার উপায় ছাড়া।

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

- **Dual-write consistency.** NEW write ব্যর্থ কিন্তু OLD সফল হলে, তারা diverge করে। OLD-কে authoritative করুন এবং CDC-কে NEW মেরামত করতে দিন, ইউজারের request ব্যর্থ করার বদলে।
- **খরচ ও জটিলতা.** দুটি database + CDC + backfill চালানো ব্যয়বহুল এবং operationally ভারী — কেবল বড়, critical store-এর জন্য যুক্তিযুক্ত।
- **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 back করতে পারেন। কেবল তখনই OLD decommission করুন।
- **কখন নয়:** একটি maintenance window সহ একটি ছোট DB-এর এটি লাগে না — একটি ৩০-মিনিটের `pg_dump`/restore একটি CDC pipeline-এর চেয়ে সরল ও নিরাপদ।

আর্কিটেকচার

কীভাবে কাজ করে

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

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

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