Hvordan synkroniserer CDC data på tvers av systemer?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** streamer hver insert/update/delete ut av en kilde-database — typisk ved å **lese dens transaksjonslogg** — og publiserer dem som events andre systemer konsumerer, slik at nedstrøms stores holder seg synkronisert uten dual-writes eller polling.

```text
  Postgres/MySQL          Debezium            Kafka topic          sinks
 ┌────────────┐  leser   ┌─────────┐  emit   ┌──────────┐  konsumer ┌───────────┐
 │ WAL/binlog │ ───────▶ │ connector│ ──────▶ │ per-tabell│ ───────▶ │ search    │
 │ (tx log)   │          │          │  events │  ordnet   │          │ warehouse │
 └────────────┘          └─────────┘          └──────────┘          │ cache     │
                                                                     └───────────┘
```

## Hvorfor log-basert CDC

Du kunne synkronisere ved polling ("rader endret siden T") eller ved å skrive til to systemer samtidig (**dual-write**), men polling går glipp av raske oppdateringer og dual-writes brytes atomisk — hvis den andre writen feiler får du divergens. **Log-basert CDC** taler i stedet databasens egen write-ahead log (Postgres **WAL**, MySQL **binlog**), den varige posten DB-en bruker for crash recovery. **Debezium** er standard-connectoren: den leser loggen og publiserer hver endring til **Kafka**, én topic per tabell — fanger *hver* endring uten belastning på spørringer og uten missede rader.

## Rekkefølge og idempotens

- **Rekkefølge:** endringer til samme rad må ankomme i rekkefølge ellers ville du applikert en gammel verdi sist. Kafka garanterer rekkefølge **innenfor en partisjon**, så partisjoner på primary key — alle endringer for én rad lander på én partisjon, i commit-rekkefølge.
- **Levering er at-least-once:** ved en retry eller connector-restart kan samme event leveres to ganger. Så **sinks må være idempotente** — nøkle writen på primary key + log-offset (LSN) slik at re-applikering av et event er en no-op. Anta aldri exactly-once.

## Intervjuperspektiv

Intervjueren sjekker om du vet at CDC slår dual-writes og *hvorfor* (atomitet, ingen missede endringer), og om du fatter **at-least-once + idempotente sinks**. Bra: "Debezium leser WAL-en inn i Kafka." Utmerket: du legger til partition-by-key for rekkefølge og idempotente sinks for duplikater. Felle: å anta exactly-once-levering, eller å ignorere at en DDL-endring på kilden kan brekke consumers.

## Avveininger og feilmoduser

- **Schema evolution:** en kolonne lagt til/droppet oppstrøms endrer event-formen — bruk et **schema registry** og kompatible endringer slik at consumers ikke brekker.
- **Initial snapshot:** CDC ser kun endringer *fra nå*; du trenger et engangs-snapshot av eksisterende rader, deretter bytte til streaming.
- **Log-retention:** hvis kilden purger loggen sin før connectoren leser den, mister du endringer — overvåk connector-lag.
- **Backpressure:** en treg sink lar Kafka-lag vokse; dimensjoner retention og consumers for peak endringsvolum.

Hvorfor log-basert CDC

Rekkefølge og idempotens

Intervjuperspektiv

Avveininger og feilmoduser

Relaterte spørsmål