Wie synchronisiert CDC Daten über Systeme hinweg?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** streamt jedes Insert/Update/Delete aus einer Quelldatenbank heraus - typischerweise durch **Lesen ihres Transaktionslogs** - und publiziert sie als Events, die andere Systeme konsumieren, sodass Downstream-Stores synchron bleiben, ohne Dual-Writes oder Polling.

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

## Warum log-basiertes CDC

Du könntest per Polling ("seit T geänderte Rows") oder durch gleichzeitiges Schreiben in zwei Systeme (**Dual-Write**) synchronisieren, aber Polling verpasst schnelle Updates und Dual-Writes brechen die Atomizität - scheitert der zweite Write, bekommst du Divergenz. **Log-basiertes CDC** liest stattdessen das eigene Write-Ahead-Log der Datenbank (Postgres **WAL**, MySQL **Binlog**), den langlebigen Datensatz, den die DB für Crash Recovery nutzt. **Debezium** ist der Standard-Connector: Er liest das Log und publiziert jede Änderung an **Kafka**, ein Topic pro Tabelle - erfasst *jede* Änderung ohne Last auf Queries und ohne verpasste Rows.

## Ordering & Idempotenz

- **Ordering:** Änderungen an derselben Row müssen in Reihenfolge ankommen, sonst würdest du einen alten Wert zuletzt anwenden. Kafka garantiert Reihenfolge **innerhalb einer Partition**, also partitioniere nach Primary Key - alle Änderungen für eine Row landen auf einer Partition, in Commit-Reihenfolge.
- **Zustellung ist At-least-once:** bei einem Retry oder Connector-Neustart kann dasselbe Event zweimal zugestellt werden. Also **müssen Sinks idempotent sein** - keye den Write nach Primary Key + Log-Offset (LSN), sodass ein erneutes Anwenden eines Events ein No-op ist. Nimm nie Exactly-once an.

## Interview-Perspektive

Der Interviewer prüft, ob du weißt, dass CDC Dual-Writes schlägt und *warum* (Atomizität, keine verpassten Änderungen), und ob du **At-least-once + idempotente Sinks** erfasst. Gut: "Debezium liest das WAL nach Kafka." Hervorragend: Du ergänzt Partition-by-Key für Ordering und idempotente Sinks für Duplikate. Falle: Exactly-once-Zustellung anzunehmen, oder zu ignorieren, dass eine DDL-Änderung an der Quelle Consumer brechen kann.

## Trade-offs & Fehlermodi

- **Schema-Evolution:** eine upstream hinzugefügte/entfernte Spalte ändert die Event-Form - nutze eine **Schema Registry** und kompatible Änderungen, damit Consumer nicht brechen.
- **Initialer Snapshot:** CDC sieht nur Änderungen *ab jetzt*; du brauchst einen einmaligen Snapshot der bestehenden Rows, dann Umschalten auf Streaming.
- **Log-Retention:** löscht die Quelle ihr Log, bevor der Connector es liest, verlierst du Änderungen - überwache den Connector-Lag.
- **Backpressure:** ein langsamer Sink lässt den Kafka-Lag wachsen; dimensioniere Retention und Consumer für Spitzen-Änderungsvolumen.

Warum log-basiertes CDC

Ordering & Idempotenz

Interview-Perspektive

Trade-offs & Fehlermodi

Ähnliche Fragen