zero downtime સાથે 10TB database migrate કરો: plan શું છે?

Question

IT Interview Practice · Accepted Answer

**old અને new બંનેમાં dual-write કરો, background માં history backfill કરો, tail catch up કરવા CDC વાપરો, shadow reads વડે verify કરો, પછી reads atomically flip કરો — દરેક step પર rollback path સાથે.** તમે ક્યારેય app down નથી લેતા; તમે નવું provably identical ન થાય ત્યાં સુધી બંને databases parallel ચલાવો છો, પછી 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 દરેક change ને OLD અને NEW બંનેમાં લખે છે. નવા rows હવેથી sync રહે છે; માત્ર history missing છે.
2. **Backfill.** એક background job historical rows ને batches માં copy કરે છે (prod ને સુરક્ષિત કરવા throttled). `INSERT ... ON CONFLICT DO NOTHING` વાપરો જેથી તે idempotent અને re-run કરવા safe હોય.
3. **CDC catch-up.** Dual-write switch-on દરમિયાન લખાયેલા rows miss કરી શકે છે. **Debezium** OLD DB ના WAL/binlog ને stream કરીને દરેક change replay કરે છે, backfill ન કરી શકે તે gap બંધ કરે છે.
4. **Shadow reads.** OLD ની સાથે parallel માં NEW માંથી read કરો, **results compare કરો**, અને diff metric emit કરો. સમય જતાં zero diffs = NEW trustworthy છે.
5. **Cutover.** એક feature flag flip કરો જેથી reads (પછી writes) NEW પર જાય. તે config change છે, deploy નહીં — instant, અને **flip back કરીને reversible**.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

ઇન્ટરવ્યૂઅર **તમે no data loss અને no downtime કેવી રીતે guarantee કરો છો**, અને શું તમારી પાસે **rollback** છે તે ઇચ્છે છે. Good answers dual-write નો ઉલ્લેખ કરે છે; great answers **race window પકડવા CDC**, **trust કરતાં પહેલાં verify કરવા shadow reads**, અને એક **atomic, reversible flag flip** ઉમેરે છે. Classic trap એ verification વગર "backfill પછી switch" છે — તમે mismatch ને users hit કર્યા પછી શોધો છો, પાછા જવાના રસ્તા વગર.

## Trade-offs અને failure

- **Dual-write consistency.** જો NEW write fail થાય પણ OLD succeed થાય, તો તે diverge થાય. OLD ને authoritative બનાવો અને user ની request fail કરવાને બદલે CDC ને NEW repair કરવા દો.
- **Cost & complexity.** બે databases + CDC + backfill ચલાવવું મોંઘું અને operationally ભારે છે — માત્ર મોટા, critical stores માટે justified.
- **Schema changes** migration દરમિયાન risk ને multiply કરે છે; cutover સુધી schema freeze કરો.
- **Backfill load.** unthrottled backfill prod I/O saturate કરી outage કરી શકે — goal ની વિરુદ્ધ; batch અને rate-limit કરો.
- **Rollback window.** cutover પછી દિવસો સુધી dual-writing (હવે NEW→OLD) રાખો જેથી latent bug ઊભરે તો flip back કરી શકો. ત્યાર પછી જ OLD decommission કરો.
- **ક્યારે ન કરવું:** maintenance window સાથે નાના DB ને આ જોઈતું નથી — એક 30-minute `pg_dump`/restore CDC pipeline કરતાં સરળ અને safer છે.

આર્કિટેક્ચર

તે કેવી રીતે કામ કરે છે

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure

સંબંધિત પ્રશ્નો