CDC systems ਦੇ ਪਾਰ data ਨੂੰ ਕਿਵੇਂ sync ਕਰਦਾ ਹੈ?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** ਹਰ insert/update/delete ਨੂੰ ਇੱਕ source database ਵਿੱਚੋਂ stream ਕਰਦਾ ਹੈ — ਆਮ ਤੌਰ ਉੱਤੇ ਇਸਦੀ **transaction log ਪੜ੍ਹ ਕੇ** — ਅਤੇ ਉਹਨਾਂ ਨੂੰ events ਵਜੋਂ publish ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਹੋਰ systems consume ਕਰਦੇ ਹਨ, ਤਾਂ ਜੋ downstream stores dual-writes ਜਾਂ polling ਤੋਂ ਬਿਨਾਂ sync ਰਹਿਣ।

```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 ("T ਤੋਂ ਬਾਅਦ ਬਦਲੀਆਂ rows") ਜਾਂ ਇੱਕੋ ਵਾਰ ਦੋ systems ਵਿੱਚ ਲਿਖ ਕੇ (**dual-write**) sync ਕਰ ਸਕਦੇ ਹੋ, ਪਰ polling ਤੇਜ਼ updates miss ਕਰਦਾ ਹੈ ਅਤੇ dual-writes atomically ਟੁੱਟਦੇ ਹਨ — ਜੇ ਦੂਜਾ write fail ਹੋ ਜਾਵੇ ਤਾਂ ਤੁਹਾਨੂੰ divergence ਮਿਲਦੀ ਹੈ। **Log-based CDC** ਇਸ ਦੀ ਬਜਾਏ database ਦੇ ਆਪਣੇ write-ahead log (Postgres **WAL**, MySQL **binlog**) ਦੀ ਪੂਛ ਫੜਦਾ ਹੈ, ਓਹ durable record ਜੋ DB crash recovery ਲਈ ਵਰਤਦਾ ਹੈ। **Debezium** standard connector ਹੈ: ਇਹ log ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਹਰ change ਨੂੰ **Kafka** ਵਿੱਚ publish ਕਰਦਾ ਹੈ, ਹਰ table ਲਈ ਇੱਕ topic — *ਹਰ* change capture ਕਰਦਾ ਹੈ ਬਿਨਾਂ queries ਉੱਤੇ load ਦੇ ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ missed rows ਦੇ।

## Ordering ਅਤੇ idempotency

- **Ordering:** ਓਹੀ row ਦੇ changes order ਵਿੱਚ ਪਹੁੰਚਣੇ ਚਾਹੀਦੇ ਹਨ ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਪੁਰਾਣਾ value ਆਖਰ ਵਿੱਚ apply ਕਰ ਦਿਓਗੇ। Kafka ਇੱਕ **partition ਦੇ ਅੰਦਰ** order ਦੀ ਗਾਰੰਟੀ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ primary key ਨਾਲ partition ਕਰੋ — ਇੱਕ row ਦੇ ਸਾਰੇ changes ਇੱਕ partition ਉੱਤੇ, commit order ਵਿੱਚ ਆ ਜਾਂਦੇ ਹਨ।
- **Delivery at-least-once ਹੈ:** ਇੱਕ retry ਜਾਂ connector restart ਉੱਤੇ ਓਹੀ event ਦੋ ਵਾਰ deliver ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ **sinks idempotent ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ** — write ਨੂੰ primary key + log offset (LSN) ਨਾਲ key ਕਰੋ ਤਾਂ ਜੋ ਇੱਕ event ਨੂੰ ਦੁਬਾਰਾ apply ਕਰਨਾ ਇੱਕ no-op ਹੋਵੇ। ਕਦੇ exactly-once ਨਾ ਮੰਨੋ।

## ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਇੰਟਰਵਿਊਅਰ ਚੈੱਕ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ CDC dual-writes ਨੂੰ ਹਰਾਉਂਦਾ ਹੈ ਅਤੇ *ਕਿਉਂ* (atomicity, ਕੋਈ missed changes ਨਹੀਂ), ਅਤੇ ਕੀ ਤੁਸੀਂ **at-least-once + idempotent sinks** ਸਮਝਦੇ ਹੋ। ਵਧੀਆ: "Debezium WAL ਨੂੰ Kafka ਵਿੱਚ ਪੜ੍ਹਦਾ ਹੈ।" ਸ਼ਾਨਦਾਰ: ਤੁਸੀਂ ordering ਲਈ partition-by-key ਅਤੇ duplicates ਲਈ idempotent sinks ਜੋੜਦੇ ਹੋ। ਫੰਦਾ: exactly-once delivery ਮੰਨਣਾ, ਜਾਂ ਇਹ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਕਿ source ਉੱਤੇ ਇੱਕ DDL change consumers ਨੂੰ ਤੋੜ ਸਕਦੀ ਹੈ।

## ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

- **Schema evolution:** upstream ਇੱਕ column ਜੋੜਨ/ਹਟਾਉਣ ਨਾਲ event shape ਬਦਲ ਜਾਂਦੀ ਹੈ — ਇੱਕ **schema registry** ਅਤੇ compatible changes ਵਰਤੋ ਤਾਂ ਜੋ consumers ਨਾ ਟੁੱਟਣ।
- **Initial snapshot:** CDC ਸਿਰਫ਼ *ਹੁਣ ਤੋਂ* changes ਦੇਖਦਾ ਹੈ; ਤੁਹਾਨੂੰ ਮੌਜੂਦਾ rows ਦੇ ਇੱਕ one-time snapshot ਦੀ ਲੋੜ ਹੈ, ਫਿਰ streaming ਵੱਲ switch ਕਰੋ।
- **Log retention:** ਜੇ source connector ਦੇ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣਾ log purge ਕਰ ਦੇਵੇ, ਤੁਸੀਂ changes ਗੁਆ ਦਿੰਦੇ ਹੋ — connector lag monitor ਕਰੋ।
- **Backpressure:** ਇੱਕ ਹੌਲੀ sink Kafka lag ਨੂੰ ਵਧਣ ਦਿੰਦਾ ਹੈ; peak change volume ਲਈ retention ਅਤੇ consumers size ਕਰੋ।

log-based CDC ਕਿਉਂ

Ordering ਅਤੇ idempotency

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

ਸੰਬੰਧਿਤ ਸਵਾਲ