Bagaimana CDC menyinkronkan data antar sistem?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** men-stream setiap insert/update/delete keluar dari database sumber — biasanya dengan **membaca transaction log-nya** — dan mempublikasikannya sebagai event yang dikonsumsi sistem lain, sehingga store downstream tetap tersinkron tanpa dual-write atau polling.

```text
  Postgres/MySQL          Debezium            Kafka topic          sinks
 ┌────────────┐  reads   ┌─────────┐  emit   ┌──────────┐  consume ┌───────────┐
 │ WAL/binlog │ ───────▶ │ connector│ ──────▶ │ per-table│ ───────▶ │ search    │
 │ (tx log)   │          │          │  events │  ordered │          │ warehouse │
 └────────────┘          └─────────┘          └──────────┘          │ cache     │
                                                                     └───────────┘
```

## Mengapa log-based CDC

Anda bisa menyinkronkan dengan polling ("baris berubah sejak T") atau dengan menulis ke dua sistem sekaligus (**dual-write**), tetapi polling melewatkan update cepat dan dual-write pecah secara atomik — jika write kedua gagal Anda mendapat divergensi. **Log-based CDC** justru menelusuri write-ahead log database itu sendiri (Postgres **WAL**, MySQL **binlog**), catatan durable yang dipakai DB untuk crash recovery. **Debezium** adalah connector standar: ia membaca log dan mempublikasikan setiap perubahan ke **Kafka**, satu topic per tabel — menangkap *setiap* perubahan tanpa beban pada query dan tanpa baris terlewat.

## Ordering & idempotency

- **Ordering:** perubahan pada baris yang sama harus tiba berurutan atau Anda akan menerapkan nilai lama terakhir. Kafka menjamin urutan **dalam satu partisi**, jadi partisi berdasarkan primary key — semua perubahan untuk satu baris mendarat di satu partisi, dalam urutan commit.
- **Pengiriman at-least-once:** saat retry atau restart connector event yang sama bisa terkirim dua kali. Jadi **sink harus idempotent** — key write berdasarkan primary key + log offset (LSN) agar menerapkan ulang event menjadi no-op. Jangan pernah mengasumsikan exactly-once.

## Perspektif wawancara

Pewawancara memeriksa apakah Anda tahu CDC mengalahkan dual-write dan *mengapa* (atomicity, tanpa perubahan terlewat), dan apakah Anda memahami **at-least-once + sink idempotent**. Baik: "Debezium membaca WAL ke Kafka." Hebat: Anda menambah partition-by-key untuk ordering dan sink idempotent untuk duplikat. Jebakan: mengasumsikan pengiriman exactly-once, atau mengabaikan bahwa perubahan DDL pada sumber bisa merusak consumer.

## Trade-off & mode kegagalan

- **Evolusi skema:** kolom ditambah/dibuang di hulu mengubah bentuk event — gunakan **schema registry** dan perubahan yang kompatibel agar consumer tidak rusak.
- **Snapshot awal:** CDC hanya melihat perubahan *sejak sekarang*; Anda butuh snapshot satu-kali dari baris yang ada, lalu beralih ke streaming.
- **Retensi log:** jika sumber menghapus log-nya sebelum connector membacanya, Anda kehilangan perubahan — monitor lag connector.
- **Backpressure:** sink lambat membuat lag Kafka tumbuh; ukur retensi dan consumer untuk volume perubahan puncak.

Mengapa log-based CDC

Ordering & idempotency

Perspektif wawancara

Trade-off & mode kegagalan

Pertanyaan terkait