Cum sincronizează CDC datele între sisteme?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** transmite fiecare insert/update/delete dintr-o bază de date sursă — de obicei prin **citirea transaction log-ului ei** — și le publică ca evenimente pe care alte sisteme le consumă, astfel încât store-urile din aval să rămână sincronizate fără dual-writes sau polling.

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

## De ce CDC log-based

Ai putea sincroniza prin polling ("rânduri modificate de la T") sau scriind în două sisteme deodată (**dual-write**), dar polling-ul ratează update-urile rapide, iar dual-write-urile se rup atomic — dacă a doua scriere eșuează, obții divergență. **CDC log-based** urmărește în schimb write-ahead log-ul propriu al bazei de date (Postgres **WAL**, MySQL **binlog**), înregistrarea durabilă pe care DB-ul o folosește pentru crash recovery. **Debezium** este connectorul standard: citește log-ul și publică fiecare modificare în **Kafka**, un topic per tabelă — capturând *fiecare* modificare fără încărcare pe interogări și fără rânduri ratate.

## Ordonare și idempotență

- **Ordonare:** modificările aceluiași rând trebuie să sosească în ordine, altfel ai aplica ultima o valoare veche. Kafka garantează ordinea **în cadrul unei partiții**, deci fă partition după cheia primară — toate modificările pentru un rând aterizează pe o partiție, în ordinea commit-ului.
- **Livrarea este at-least-once:** la o reîncercare sau un restart de connector, același eveniment poate fi livrat de două ori. Deci **sink-urile trebuie să fie idempotente** — cheiază scrierea după cheia primară + offset-ul de log (LSN), astfel încât re-aplicarea unui eveniment să fie un no-op. Nu presupune niciodată exactly-once.

## Perspectiva de interviu

Intervievatorul verifică dacă știi că CDC bate dual-writes și *de ce* (atomicitate, fără modificări ratate) și dacă înțelegi **at-least-once + sink-uri idempotente**. Bine: "Debezium citește WAL-ul în Kafka." Excelent: adaugi partition-by-key pentru ordonare și sink-uri idempotente pentru dubluri. Capcană: a presupune livrare exactly-once, sau a ignora că o modificare DDL pe sursă poate rupe consumerii.

## Compromisuri și moduri de eșec

- **Evoluția schemei:** o coloană adăugată/eliminată în amonte schimbă forma evenimentului — folosește un **schema registry** și modificări compatibile, astfel încât consumerii să nu se rupă.
- **Snapshot inițial:** CDC vede doar modificările *de acum*; ai nevoie de un snapshot unic al rândurilor existente, apoi comuți la streaming.
- **Retenția log-ului:** dacă sursa își purjează log-ul înainte ca connectorul să-l citească, pierzi modificări — monitorizează lag-ul connectorului.
- **Backpressure:** un sink lent lasă lag-ul Kafka să crească; dimensionează retenția și consumerii pentru volumul de modificări de vârf.

De ce CDC log-based

Ordonare și idempotență

Perspectiva de interviu

Compromisuri și moduri de eșec

Întrebări conexe