CDC ले system हरूबीच data कसरी sync गर्छ?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** ले एउटा source database बाट प्रत्येक insert/update/delete stream गर्छ — सामान्यतया यसको **transaction log पढेर** — र तिनलाई अरू system ले consume गर्ने event को रूपमा publish गर्छ, ताकि downstream store dual-write वा 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 देखि बदलिएका row") वा एकैचोटि दुई system मा लेखेर (**dual-write**) sync गर्न सक्नुहुन्थ्यो, तर polling ले छिटो update छुटाउँछ र dual-write atomically भाँचिन्छ — दोस्रो write fail भए तपाईं विचलन पाउनुहुन्छ। **Log-based CDC** ले बरु database को आफ्नै write-ahead log (Postgres **WAL**, MySQL **binlog**) — DB ले crash recovery का लागि प्रयोग गर्ने टिकाउ record — tail गर्छ। **Debezium** standard connector हो: यसले log पढ्छ र प्रत्येक change लाई **Kafka** मा publish गर्छ, प्रति table एउटा topic — कुनै query load बिना र कुनै row नछुटाई *प्रत्येक* change capture गर्छ।

## Ordering र idempotency

- **Ordering:** एउटै row का change क्रममा आउनैपर्छ नत्र तपाईंले पुरानो value अन्तिममा apply गर्नुहुन्छ। Kafka ले **partition भित्र** क्रम ग्यारेन्टी गर्छ, त्यसैले primary key अनुसार partition गर्नुहोस् — एउटा row का सबै change एउटा partition मा, commit क्रममा पर्छन्।
- **Delivery at-least-once छ:** retry वा connector restart मा एउटै event दुई पटक deliver हुन सक्छ। त्यसैले **sink idempotent हुनैपर्छ** — write लाई primary key + log offset (LSN) मा key गर्नुहोस् ताकि event पुनः-apply गर्नु no-op होस्। कहिल्यै exactly-once नमान्नुहोस्।

## अन्तर्वार्ता दृष्टिकोण

अन्तर्वार्ताकारले तपाईंले CDC ले dual-write जित्छ र *किन* (atomicity, छुटेको change छैन) जान्नुहुन्छ कि, र **at-least-once + idempotent sink** बुझ्नुहुन्छ कि जाँच्छन्। राम्रो: "Debezium ले WAL लाई Kafka मा पढ्छ।" उत्कृष्ट: तपाईं ordering का लागि partition-by-key र duplicate का लागि idempotent sink थप्नुहुन्छ। जाल: exactly-once delivery मान्नु, वा source मा DDL change ले consumer भाँच्न सक्छ भनेर बेवास्ता गर्नु।

## ट्रेड-अफ र failure mode

- **Schema evolution:** upstream मा column थपिँदा/हटाइँदा event आकार बदलिन्छ — **schema registry** र compatible change प्रयोग गर्नुहोस् ताकि consumer नभाँचियोस्।
- **Initial snapshot:** CDC ले *अबदेखि* का change मात्र देख्छ; तपाईंलाई अवस्थित row को एक-पटके snapshot चाहिन्छ, अनि streaming मा switch गर्नुहोस्।
- **Log retention:** source ले connector ले पढ्नुअघि आफ्नो log purge गर्‍यो भने, तपाईं change गुमाउनुहुन्छ — connector lag monitor गर्नुहोस्।
- **Backpressure:** ढिलो sink ले Kafka lag बढ्न दिन्छ; peak change volume का लागि retention र consumer size गर्नुहोस्।

किन log-based CDC

Ordering र idempotency

अन्तर्वार्ता दृष्टिकोण

ट्रेड-अफ र failure mode

सम्बन्धित प्रश्नहरू