Kako CDC sinkronizira podatke između sustava?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** streama svaki insert/update/delete iz izvorne baze — obično **čitanjem njezinog transakcijskog loga** — i objavljuje ih kao događaje koje drugi sustavi konzumiraju, tako da nizvodni storeovi ostaju sinkronizirani bez dual-writeova ili pollanja.

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

## Zašto log-based CDC

Mogli biste sinkronizirati pollanjem ("retci promijenjeni od T") ili upisom u dva sustava odjednom (**dual-write**), ali pollanje propušta brza ažuriranja a dual-writeovi pucaju atomski — ako drugi upis padne, dobijete razilaženje. **Log-based CDC** umjesto toga prati vlastiti write-ahead log baze (Postgres **WAL**, MySQL **binlog**), trajni zapis koji baza koristi za crash recovery. **Debezium** je standardni konektor: čita log i objavljuje svaku promjenu u **Kafku**, jedan topic po tablici — hvatajući *svaku* promjenu bez opterećenja upita i bez propuštenih redaka.

## Redoslijed i idempotentnost

- **Redoslijed:** promjene istog retka moraju stići u redoslijedu ili biste primijenili staru vrijednost zadnju. Kafka jamči redoslijed **unutar particije**, pa particionirajte po primarnom ključu — sve promjene za jedan redak završe na jednoj particiji, u redoslijedu commita.
- **Isporuka je at-least-once:** pri retryju ili restartu konektora isti se događaj može isporučiti dvaput. Pa **sinkovi moraju biti idempotentni** — ključajte upis po primarnom ključu + log offsetu (LSN) tako da je ponovna primjena događaja no-op. Nikad ne pretpostavljajte exactly-once.

## Perspektiva intervjua

Ispitivač provjerava znate li da CDC pobjeđuje dual-writeove i *zašto* (atomičnost, bez propuštenih promjena) i shvaćate li **at-least-once + idempotentne sinkove**. Dobro: "Debezium čita WAL u Kafku." Odlično: dodajete partition-by-key za redoslijed i idempotentne sinkove za duplikate. Zamka: pretpostaviti exactly-once isporuku, ili zanemariti da DDL promjena na izvoru može slomiti consumere.

## Kompromisi i načini otkazivanja

- **Evolucija sheme:** stupac dodan/izbačen uzvodno mijenja oblik događaja — koristite **schema registry** i kompatibilne promjene tako da se consumeri ne slome.
- **Početni snapshot:** CDC vidi samo promjene *od sada*; trebate jednokratni snapshot postojećih redaka, pa prebacite na streaming.
- **Zadržavanje loga:** ako izvor očisti log prije nego što ga konektor pročita, gubite promjene — nadzirite lag konektora.
- **Backpressure:** spor sink dopušta rast Kafka laga; dimenzionirajte zadržavanje i consumere za vršni volumen promjena.

Zašto log-based CDC

Redoslijed i idempotentnost

Perspektiva intervjua

Kompromisi i načini otkazivanja

Povezana pitanja