Πώς συγχρονίζει το CDC δεδομένα μεταξύ συστημάτων;

Question

IT Interview Practice · Accepted Answer

Το **Change Data Capture (CDC)** κάνει stream κάθε insert/update/delete έξω από μια source βάση — τυπικά **διαβάζοντας το transaction log της** — και τα δημοσιεύει ως events που άλλα συστήματα καταναλώνουν, ώστε τα downstream stores να μένουν σε sync χωρίς dual-writes ή polling.

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

## Γιατί log-based CDC

Θα μπορούσατε να συγχρονίσετε κάνοντας polling ("rows που άλλαξαν από το T") ή γράφοντας σε δύο συστήματα ταυτόχρονα (**dual-write**), αλλά το polling χάνει γρήγορα updates και τα dual-writes σπάνε ατομικά — αν το δεύτερο write αποτύχει παίρνετε απόκλιση. Το **log-based CDC** αντ' αυτού παρακολουθεί το write-ahead log της ίδιας της βάσης (Postgres **WAL**, MySQL **binlog**), το durable record που η βάση χρησιμοποιεί για crash recovery. Το **Debezium** είναι ο standard connector: διαβάζει το log και δημοσιεύει κάθε αλλαγή στο **Kafka**, ένα topic ανά πίνακα — αποτυπώνοντας *κάθε* αλλαγή χωρίς load στα queries και χωρίς χαμένα rows.

## Ordering & idempotency

- **Ordering:** οι αλλαγές στην ίδια row πρέπει να φτάνουν με τη σειρά αλλιώς θα εφαρμόζατε μια παλιά τιμή τελευταία. Το Kafka εγγυάται τη σειρά **μέσα σε ένα partition**, οπότε κάντε partition κατά primary key — όλες οι αλλαγές για μια row προσγειώνονται σε ένα partition, με τη σειρά commit.
- **Το delivery είναι at-least-once:** σε ένα retry ή restart του connector το ίδιο event μπορεί να παραδοθεί δύο φορές. Οπότε **τα sinks πρέπει να είναι idempotent** — κάντε key το write κατά primary key + log offset (LSN) ώστε η επανεφαρμογή ενός event να είναι no-op. Ποτέ μην υποθέτετε exactly-once.

## Οπτική συνέντευξης

Ο συνεντευκτής ελέγχει αν ξέρετε ότι το CDC κερδίζει τα dual-writes και *γιατί* (atomicity, καμία χαμένη αλλαγή), και αν κατανοείτε το **at-least-once + idempotent sinks**. Καλό: "το Debezium διαβάζει το WAL στο Kafka." Εξαιρετικό: προσθέτετε partition-by-key για ordering και idempotent sinks για duplicates. Παγίδα: να υποθέτετε exactly-once delivery, ή να αγνοείτε ότι μια DDL αλλαγή στην πηγή μπορεί να σπάσει τους consumers.

## Trade-offs & τρόποι αποτυχίας

- **Schema evolution:** μια column που προστίθεται/αφαιρείται upstream αλλάζει το σχήμα του event — χρησιμοποιήστε ένα **schema registry** και compatible αλλαγές ώστε οι consumers να μη σπάνε.
- **Initial snapshot:** το CDC βλέπει μόνο αλλαγές *από τώρα*· χρειάζεστε ένα εφάπαξ snapshot των υπαρχόντων rows, μετά μετάβαση σε streaming.
- **Log retention:** αν η πηγή καθαρίσει το log της πριν το διαβάσει ο connector, χάνετε αλλαγές — monitor το connector lag.
- **Backpressure:** ένα αργό sink αφήνει το Kafka lag να μεγαλώσει· διαστασιολογήστε το retention και τους consumers για peak change volume.

Γιατί log-based CDC

Ordering & idempotency

Οπτική συνέντευξης

Trade-offs & τρόποι αποτυχίας

Σχετικές ερωτήσεις