Hvordan synkroniserer CDC data på tværs af systemer?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** streamer hver insert/update/delete ud af en source-database — typisk ved at **læse dens transaction log** — og publicerer dem som events, andre systemer konsumerer, så downstream stores forbliver i sync uden dual-writes eller polling.

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

## Hvorfor log-baseret CDC

Du kunne synkronisere ved polling ("rows ændret siden T") eller ved at skrive til to systemer samtidigt (**dual-write**), men polling misser hurtige updates og dual-writes brydes atomart — hvis det andet write fejler får du divergens. **Log-baseret CDC** haler i stedet databasens egen write-ahead log (Postgres **WAL**, MySQL **binlog**), den holdbare record DB'en bruger til crash recovery. **Debezium** er standard-connectoren: den læser loggen og publicerer hver ændring til **Kafka**, ét topic pr. tabel — indfanger *hver* ændring uden belastning på forespørgsler og uden missede rows.

## Ordering & idempotens

- **Ordering:** ændringer til samme row skal ankomme i rækkefølge, ellers ville du anvende en gammel værdi sidst. Kafka garanterer rækkefølge **inden for en partition**, så partitionér efter primærnøgle — alle ændringer for én row lander på én partition, i commit-rækkefølge.
- **Delivery er at-least-once:** ved en retry eller connector-genstart kan samme event leveres to gange. Så **sinks skal være idempotente** — nøgl write'et på primærnøgle + log offset (LSN) så at genanvende et event er en no-op. Antag aldrig exactly-once.

## Interview-perspektiv

Intervieweren tjekker, om du ved, at CDC slår dual-writes og *hvorfor* (atomicitet, ingen missede ændringer), og om du greber **at-least-once + idempotente sinks**. Godt: "Debezium læser WAL ind i Kafka." Fremragende: du tilføjer partition-by-key til ordering og idempotente sinks til dubletter. Fælde: at antage exactly-once delivery, eller at ignorere, at en DDL-ændring på kilden kan bryde consumers.

## Trade-offs & fejlmåder

- **Schema evolution:** en kolonne tilføjet/droppet upstream ændrer event-formen — brug et **schema registry** og kompatible ændringer så consumers ikke brydes.
- **Initial snapshot:** CDC ser kun ændringer *fra nu*; du har brug for et engangs-snapshot af eksisterende rows, skift derefter til streaming.
- **Log retention:** hvis kilden renser sin log før connectoren læser den, mister du ændringer — monitorér connector-lag.
- **Backpressure:** en langsom sink lader Kafka-lag vokse; dimensionér retention og consumers til peak change-volumen.

Hvorfor log-baseret CDC

Ordering & idempotens

Interview-perspektiv

Trade-offs & fejlmåder

Relaterede spørgsmål