Come sincronizza i dati tra sistemi il CDC?

Question

IT Interview Practice · Accepted Answer

Il **Change Data Capture (CDC)** fa streaming di ogni insert/update/delete da un database sorgente — tipicamente **leggendone il transaction log** — e li pubblica come eventi che altri sistemi consumano, così che gli store a valle restino sincronizzati senza dual-write o polling.

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

## Perché il CDC log-based

Potresti sincronizzare con il polling ("righe cambiate da T") o scrivendo su due sistemi contemporaneamente (**dual-write**), ma il polling perde gli aggiornamenti rapidi e i dual-write si rompono atomicamente — se la seconda scrittura fallisce ottieni divergenza. Il **CDC log-based** invece segue il write-ahead log del database stesso (il **WAL** di Postgres, il **binlog** di MySQL), il record durevole che il DB usa per il crash recovery. **Debezium** è il connettore standard: legge il log e pubblica ogni cambiamento su **Kafka**, un topic per tabella — catturando *ogni* cambiamento senza carico sulle query e senza righe perse.

## Ordinamento e idempotenza

- **Ordinamento:** i cambiamenti alla stessa riga devono arrivare in ordine, altrimenti applicheresti un valore vecchio per ultimo. Kafka garantisce l'ordine **all'interno di una partizione**, quindi partiziona per primary key — tutti i cambiamenti di una riga finiscono su una partizione, in ordine di commit.
- **La consegna è at-least-once:** su un retry o al restart del connettore lo stesso evento può essere consegnato due volte. Quindi **i sink devono essere idempotenti** — indicizza la scrittura per primary key + offset del log (LSN) così che ri-applicare un evento sia un no-op. Non assumere mai l'exactly-once.

## Prospettiva del colloquio

L'intervistatore verifica se sai che il CDC batte i dual-write e *perché* (atomicità, nessun cambiamento perso), e se afferri l'**at-least-once + sink idempotenti**. Buono: "Debezium legge il WAL in Kafka." Eccellente: aggiungi il partition-by-key per l'ordinamento e i sink idempotenti per i duplicati. Trappola: assumere la consegna exactly-once, o ignorare che un cambiamento DDL sulla sorgente può rompere i consumer.

## Compromessi e modalità di guasto

- **Evoluzione dello schema:** una colonna aggiunta/eliminata a monte cambia la forma dell'evento — usa uno **schema registry** e cambiamenti compatibili così che i consumer non si rompano.
- **Snapshot iniziale:** il CDC vede solo i cambiamenti *da ora*; ti serve uno snapshot una tantum delle righe esistenti, poi passi allo streaming.
- **Retention del log:** se la sorgente purga il suo log prima che il connettore lo legga, perdi cambiamenti — monitora il lag del connettore.
- **Backpressure:** un sink lento fa crescere il lag di Kafka; dimensiona retention e consumer per il volume di cambiamenti di picco.

Perché il CDC log-based

Ordinamento e idempotenza

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate