Hur synkroniserar CDC data över system?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** strömmar varje insert/update/delete ut ur en källdatabas — vanligtvis genom att **läsa dess transaktionslogg** — och publicerar dem som händelser som andra system konsumerar, så att nedströms-stores håller sig synkade utan dubbelskrivningar eller polling.

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

## Varför log-baserad CDC

Du skulle kunna synka genom polling ("rader ändrade sedan T") eller genom att skriva till två system samtidigt (**dual-write**), men polling missar snabba uppdateringar och dubbelskrivningar bryter atomiskt — om den andra skrivningen misslyckas får du divergens. **Log-baserad CDC** följer istället databasens egen write-ahead log (Postgres **WAL**, MySQL **binlog**), den hållbara posten DB:n använder för crash recovery. **Debezium** är standardkonnektorn: den läser loggen och publicerar varje ändring till **Kafka**, en topic per tabell — fångar *varje* ändring utan last på frågor och utan missade rader.

## Ordning & idempotens

- **Ordning:** ändringar till samma rad måste anlända i ordning annars skulle du applicera ett gammalt värde sist. Kafka garanterar ordning **inom en partition**, så partitionera på primärnyckel — alla ändringar för en rad landar på en partition, i commit-ordning.
- **Leverans är at-least-once:** vid ett omförsök eller en konnektor-omstart kan samma händelse levereras två gånger. Så **sinks måste vara idempotenta** — nyckla skrivningen på primärnyckel + log offset (LSN) så att omapplicering av en händelse är en no-op. Anta aldrig exactly-once.

## Intervjuperspektiv

Intervjuaren kontrollerar om du vet att CDC slår dubbelskrivningar och *varför* (atomicitet, inga missade ändringar), och om du greppar **at-least-once + idempotenta sinks**. Bra: "Debezium läser WAL:en in i Kafka." Utmärkt: du lägger till partition-på-nyckel för ordning och idempotenta sinks för dubbletter. Fälla: att anta exactly-once-leverans, eller att ignorera att en DDL-ändring på källan kan bryta consumers.

## Avvägningar & felmoder

- **Schema-evolution:** en kolumn tillagd/borttagen uppströms ändrar händelsens form — använd ett **schema registry** och kompatibla ändringar så att consumers inte bryts.
- **Initial snapshot:** CDC ser bara ändringar *från och med nu*; du behöver en engångs-snapshot av befintliga rader, byt sedan till strömning.
- **Log-retention:** om källan rensar sin logg innan konnektorn läser den förlorar du ändringar — övervaka konnektor-lag.
- **Backpressure:** en långsam sink låter Kafka-lag växa; dimensionera retention och consumers för topp-ändringsvolym.

Varför log-baserad CDC

Ordning & idempotens

Intervjuperspektiv

Avvägningar & felmoder

Relaterade frågor