Si e sinkronizon CDC të dhënat nëpër sisteme?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** bën stream të çdo insert/update/delete jashtë një baze burimore — zakonisht duke **lexuar transaction log-un e saj** — dhe i publikon si event-e që sisteme të tjera i konsumojnë, kështu që store-t downstream mbeten në sync pa dual-writes ose polling.

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

## Pse log-based CDC

Mund të bënit sync me polling ("rreshtat e ndryshuar që nga T") ose duke shkruar te dy sisteme njëherësh (**dual-write**), por polling humbet update-et e shpejta dhe dual-writes thyhen atomikisht — nëse shkrimi i dytë dështon merrni divergjencë. **Log-based CDC** në vend të kësaj ndjek vetë write-ahead log-un e bazës (Postgres **WAL**, MySQL **binlog**), regjistrin e qëndrueshëm që DB përdor për crash recovery. **Debezium** është connector-i standard: lexon log-un dhe publikon çdo ndryshim te **Kafka**, një topic për çdo tabelë — duke kapur *çdo* ndryshim pa ngarkesë në query dhe pa rreshta të humbur.

## Ordering & idempotency

- **Ordering:** ndryshimet në të njëjtin row duhet të mbërrijnë në renditje ose do të aplikonit një vlerë të vjetër të fundit. Kafka garanton renditje **brenda një partition**, kështu që partition sipas primary key — të gjitha ndryshimet për një row bien në një partition, në renditje commit-i.
- **Dorëzimi është at-least-once:** në një retry ose restart connector-i i njëjti event mund të dorëzohet dy herë. Kështu **sinks duhet të jenë idempotentë** — indeksoni shkrimin sipas primary key + log offset (LSN) që ri-aplikimi i një event-i të jetë no-op. Kurrë mos supozoni exactly-once.

## Këndvështrimi i intervistës

Intervistuesi kontrollon nëse dini se CDC mund dual-writes dhe *pse* (atomicitet, pa ndryshime të humbura), dhe nëse e kapni **at-least-once + idempotent sinks**. Mirë: "Debezium lexon WAL në Kafka." E shkëlqyer: shtoni partition-sipas-key për renditje dhe idempotent sinks për dublikatat. Kurthi: supozimi i dorëzimit exactly-once, ose injorimi se një ndryshim DDL në burim mund të thyejë consumers.

## Kompromiset & mënyrat e dështimit

- **Schema evolution:** një kolonë e shtuar/hequr upstream ndryshon formën e event-it — përdorni një **schema registry** dhe ndryshime të përputhshme që consumers të mos thyhen.
- **Initial snapshot:** CDC sheh vetëm ndryshimet *nga tani*; ju duhet një snapshot një-herësh i rreshtave ekzistues, pastaj kaloni te streaming.
- **Log retention:** nëse burimi pastron log-un e vet para se connector-i ta lexojë, humbni ndryshime — monitoroni connector lag.
- **Backpressure:** një sink i ngadaltë lejon Kafka lag të rritet; dimensiononi retention dhe consumers për vëllimin e pikut të ndryshimeve.

Pse log-based CDC

Ordering & idempotency

Këndvështrimi i intervistës

Kompromiset & mënyrat e dështimit

Pyetje të ngjashme