Migrasikan database 10TB dengan zero downtime: apa rencananya?

Question

IT Interview Practice · Accepted Answer

**Dual-write ke lama dan baru, backfill histori di latar belakang, gunakan CDC untuk mengejar sisa (tail), verifikasi dengan shadow read, lalu balik baca secara atomik — dengan jalur rollback di setiap langkah.** Anda tidak pernah menghentikan app; Anda menjalankan kedua database paralel sampai yang baru terbukti identik, lalu cutover.

## Arsitektur

```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)
```

## Cara kerjanya

1. **Dual-write.** App menulis setiap perubahan ke OLD dan NEW. Baris baru tetap tersinkron sejak sekarang; hanya histori yang belum ada.
2. **Backfill.** Sebuah background job menyalin baris historis dalam batch (di-throttle untuk melindungi prod). Gunakan `INSERT ... ON CONFLICT DO NOTHING` agar idempotent dan aman dijalankan ulang.
3. **CDC catch-up.** Dual-write bisa melewatkan baris yang ditulis selama switch-on. **Debezium** yang men-stream WAL/binlog OLD DB me-replay setiap perubahan, menutup celah yang tak bisa diisi backfill.
4. **Shadow read.** Baca dari NEW paralel dengan OLD, **bandingkan hasilnya**, dan pancarkan metrik diff. Nol diff dari waktu ke waktu = NEW dapat dipercaya.
5. **Cutover.** Balik sebuah feature flag agar baca (lalu write) pergi ke NEW. Ini perubahan konfigurasi, bukan deploy — instan, dan **reversible dengan membalik kembali**.

## Perspektif wawancara

Pewawancara ingin tahu **bagaimana Anda menjamin tanpa kehilangan data dan tanpa downtime**, dan apakah Anda punya **rollback**. Jawaban baik menyebut dual-write; jawaban hebat menambah **CDC untuk menangkap jendela race**, **shadow read untuk verifikasi sebelum memercayai**, dan **balik flag atomik yang reversible**. Jebakan klasik adalah "backfill lalu switch" tanpa verifikasi — Anda menemukan ketidakcocokan setelah pengguna terkena, tanpa jalan kembali.

## Trade-off & kegagalan

- **Konsistensi dual-write.** Jika write NEW gagal tetapi OLD berhasil, keduanya berdivergensi. Jadikan OLD otoritatif dan biarkan CDC memperbaiki NEW, alih-alih menggagalkan request pengguna.
- **Biaya & kompleksitas.** Menjalankan dua database + CDC + backfill itu mahal dan berat operasional — dibenarkan hanya untuk store besar dan kritis.
- **Perubahan skema** selama migrasi melipatgandakan risiko; bekukan skema sampai cutover.
- **Beban backfill.** Backfill tanpa throttle bisa menjenuhkan I/O prod dan menyebabkan padam — kebalikan dari tujuan; batch dan rate-limit.
- **Jendela rollback.** Terus dual-write (kini NEW→OLD) selama berhari-hari setelah cutover agar Anda bisa membalik kembali jika bug laten muncul. Baru setelah itu dekomisikan OLD.
- **Kapan tidak perlu:** DB kecil dengan jendela maintenance tidak butuh ini — `pg_dump`/restore 30 menit lebih sederhana dan lebih aman daripada pipeline CDC.

Arsitektur

Cara kerjanya

Perspektif wawancara

Trade-off & kegagalan

Pertanyaan terkait