Hoe synchroniseert CDC data tussen systemen?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** streamt elke insert/update/delete uit een bron-database — typisch door **de transaction log te lezen** — en publiceert ze als events die andere systemen consumeren, zodat downstream-stores in sync blijven zonder dual-writes of polling.

```text
  Postgres/MySQL          Debezium            Kafka topic          sinks
 ┌────────────┐  leest   ┌─────────┐  emit   ┌──────────┐ consumeert ┌───────────┐
 │ WAL/binlog │ ───────▶ │ connector│ ──────▶ │ per-tabel│ ─────────▶ │ search    │
 │ (tx log)   │          │          │  events │  geordend│            │ warehouse │
 └────────────┘          └─────────┘          └──────────┘            │ cache     │
                                                                       └───────────┘
```

## Waarom log-based CDC

Je zou kunnen syncen door te pollen ("rows gewijzigd sinds T") of door naar twee systemen tegelijk te schrijven (**dual-write**), maar polling mist snelle updates en dual-writes breken atomiciteit — als de tweede write faalt krijg je divergentie. **Log-based CDC** tailt in plaats daarvan de eigen write-ahead log van de database (Postgres **WAL**, MySQL **binlog**), de duurzame registratie die de DB gebruikt voor crash recovery. **Debezium** is de standaardconnector: het leest de log en publiceert elke wijziging naar **Kafka**, één topic per tabel — *elke* wijziging vastleggend zonder belasting op queries en zonder gemiste rows.

## Ordening & idempotentie

- **Ordening:** wijzigingen aan dezelfde row moeten in volgorde aankomen, anders pas je een oude waarde als laatste toe. Kafka garandeert volgorde **binnen een partitie**, dus partitioneer op primary key — alle wijzigingen voor één row landen op één partitie, in commit-volgorde.
- **Bezorging is at-least-once:** bij een retry of connector-herstart kan hetzelfde event twee keer worden bezorgd. Dus **sinks moeten idempotent zijn** — key de write op primary key + log-offset (LSN) zodat het opnieuw toepassen van een event een no-op is. Neem nooit exactly-once aan.

## Interviewperspectief

De interviewer checkt of je weet dat CDC dual-writes verslaat en *waarom* (atomiciteit, geen gemiste wijzigingen), en of je **at-least-once + idempotente sinks** begrijpt. Goed: "Debezium leest de WAL in Kafka." Uitstekend: je voegt partition-by-key voor ordening en idempotente sinks voor dubbelingen toe. Valkuil: exactly-once-bezorging aannemen, of negeren dat een DDL-wijziging op de bron consumers kan breken.

## Afwegingen & faalmodi

- **Schema-evolutie:** een kolom die upstream wordt toegevoegd/verwijderd verandert de event-vorm — gebruik een **schema registry** en compatibele wijzigingen zodat consumers niet breken.
- **Initiële snapshot:** CDC ziet alleen wijzigingen *van nu af*; je hebt een eenmalige snapshot van bestaande rows nodig, dan schakel je over op streaming.
- **Log-retentie:** als de bron zijn log opruimt vóór de connector hem leest, verlies je wijzigingen — monitor connector-lag.
- **Backpressure:** een trage sink laat Kafka-lag groeien; dimensioneer retentie en consumers voor het piek-wijzigingsvolume.

Waarom log-based CDC

Ordening & idempotentie

Interviewperspectief

Afwegingen & faalmodi

Gerelateerde vragen