CDC systems میں ڈیٹا کیسے sync کرتا ہے؟

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** ایک source database سے ہر insert/update/delete نکالتا ہے — عموماً اس کے **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 چھوڑ دیتا ہے اور dual-writes atomically ٹوٹتی ہیں — اگر دوسری write ناکام ہو تو آپ کو divergence ملتا ہے۔ **Log-based CDC** اس کے بجائے database کے اپنے write-ahead log کی پیروی کرتا ہے (Postgres **WAL**، MySQL **binlog**)، وہ durable record جو DB crash recovery کے لیے استعمال کرتا ہے۔ **Debezium** معیاری connector ہے: یہ log پڑھتا ہے اور ہر تبدیلی کو **Kafka** پر publish کرتا ہے، فی table ایک topic — *ہر* تبدیلی پکڑتے ہوئے بغیر queries پر load اور بغیر rows چھوڑے۔

## Ordering اور idempotency

- **Ordering:** ایک ہی row کی تبدیلیاں ترتیب میں پہنچنی چاہئیں ورنہ آپ ایک پرانی value آخر میں لاگو کر لیں گے۔ Kafka ایک **partition کے اندر** ترتیب کی ضمانت دیتا ہے، لہٰذا primary key سے partition کریں — ایک row کی تمام تبدیلیاں ایک partition پر، commit ترتیب میں آتی ہیں۔
- **Delivery at-least-once ہے:** ایک retry یا connector restart پر ایک ہی event دو بار deliver ہو سکتا ہے۔ لہٰذا **sinks کو idempotent ہونا چاہیے** — write کو primary key + log offset (LSN) سے key کریں تاکہ ایک event دوبارہ لاگو کرنا no-op ہو۔ کبھی exactly-once فرض نہ کریں۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والا جانچتا ہے کہ کیا آپ جانتے ہیں کہ CDC dual-writes کو مات دیتا ہے اور *کیوں* (atomicity، کوئی چھوٹی تبدیلی نہیں)، اور کیا آپ **at-least-once + idempotent sinks** سمجھتے ہیں۔ اچھا: "Debezium WAL کو Kafka میں پڑھتا ہے۔" عمدہ: آپ ordering کے لیے partition-by-key اور duplicates کے لیے idempotent sinks شامل کرتے ہیں۔ جال: exactly-once delivery فرض کرنا، یا نظرانداز کرنا کہ source پر ایک DDL تبدیلی consumers کو توڑ سکتی ہے۔

## توازن اور ناکامی کے طریقے

- **Schema evolution:** upstream ایک column شامل/حذف کرنا event کی شکل بدلتا ہے — ایک **schema registry** اور مطابق تبدیلیاں استعمال کریں تاکہ consumers نہ ٹوٹیں۔
- **Initial snapshot:** CDC صرف *اب سے* تبدیلیاں دیکھتا ہے؛ آپ کو موجودہ rows کا ایک بار کا snapshot چاہیے، پھر streaming پر switch کریں۔
- **Log retention:** اگر source connector کے پڑھنے سے پہلے اپنا log purge کر دے، تو آپ تبدیلیاں کھو دیتے ہیں — connector lag monitor کریں۔
- **Backpressure:** ایک سست sink Kafka lag بڑھنے دیتا ہے؛ peak change volume کے لیے retention اور consumers کا سائز طے کریں۔

Log-based CDC کیوں

Ordering اور idempotency

انٹرویو کا نقطۂ نظر

توازن اور ناکامی کے طریقے

متعلقہ سوالات