Change Data Capture (CDC)

DBA-রা stability conservative থাকেন — যৌক্তিক কারণে। Core banking-এ ১ সেকেন্ড downtime মানে BDT লক্ষ-কোটি হারানো। তাই argument data-driven ও risk-aware হতে হবে।

Argument 1 — Source load comparison:

• Current batch: প্রতি ১৫ মিনিটে SELECT * FROM transactions WHERE updated_at > ?। যদি ১০ লক্ষ row scan হয় — buffer pool eviction, lock contention, query plan disruption।
• CDC log-based: binlog একটি sequential file — DB এটি rapidly fsync করে disk-এ। Debezium সেই file-ই পড়ে (replica-র মতো)। DB-র query engine-এ কোনো load নেই; শুধু binlog reader-এর কিছু network bandwidth।
• Empirical: large bank-এ batch query CPU ১৫-২৫% spike দেখায়; CDC ১-৩%।

Argument 2 — Replication-এর সমান সাবধানতা:

• "Binlog তো replica-র জন্য — আপনার team replication চালাচ্ছেন না কী?" — হ্যাঁ, prod-এ standby MySQL আছে। Debezium সেই same protocol ব্যবহার করে — শুধু আরেকটা replica যেন।
• Performance impact prod-এ একই — replica-র মতো।

Argument 3 — Risk mitigation:

• প্রথমে staging-এ চালান, ২ সপ্তাহ। সব load metric (CPU, IO, replication lag) compare।
• Production-এ read-replica থেকে CDC — primary-তে কোনো ছোঁয়া নেই। DBA-র সবচেয়ে বড় ভয় দূর।
• Snapshot phase carefully tune — snapshot.locking.mode=minimal বা none, off-peak হোক।
• Connector পুরোপুরি কোনো ক্ষতিকর effect-এ pause/stop করার ability — DBA-র control।

Argument 4 — Business value:

• Latency ১৫ min → ১-২ second — fraud detection-এ এটা গেম-চেঞ্জার। ভাবুন ১০ মিনিটে ৫০ লক্ষ TK suspicious transfer; আপনি ১ minute-এ ধরে ৫ minute-এ block করতে পারবেন।
• DELETE detection — current batch সম্পূর্ণ miss করে, যা compliance audit-এ ভয়াবহ।
• Multiple consumer একই stream subscribe — risk, fraud, KYC, marketing — প্রতি team-এর আলাদা batch query bypass।

Argument 5 — Industry precedent:

• JPMorgan, Goldman, ING — সবাই Debezium-based CDC production-এ চালায়।
• Bangladesh-এ Brac Bank, City Bank-এর modern data team-এ এটা চালু হচ্ছে।
• "Industry standard" বললে DBA-রা আরো comfortable।

DBA-র objections আগেই address করুন:

• "Binlog disk-fill হবে" → retention policy + monitoring; standby-র জন্য already retained।
• "Schema change-এ break হবে" → Debezium schema evolution support; DDL events captured।
• "Network failure-এ data loss" → checkpoint + replay from last LSN — exactly-once recovery।

মূল উপলব্ধি: CDC sales pitch শুধু feature list নয় — risk mitigation plan। DBA-র মতো production-conscious stakeholder-কে শুধু performance data, gradual rollout, এবং rollback plan দেখাতে পারলেই তারা buy-in দেন। Engineering = communication + persuasion + technology।

Schema evolution distributed system-এর সবচেয়ে কঠিন সমস্যাগুলোর একটি। CDC pipeline-এ এটা বিশেষভাবে — কারণ producer (DB) আর consumer-এর version unsynchronized হতে পারে দিনের পর দিন।

Debezium কীভাবে handle করে:

• include.schema.changes=true — DDL event আলাদা topic-এ publish হয়।
• Connector internal "schema history" topic-এ সব DDL track করে; binlog-এ এক বছর আগের event এলেও — সেই version-এর schema দিয়ে decode সম্ভব।
• নতুন event-এ নতুন field automatically appear।

Consumer side challenge:

• Search index (Elasticsearch): dynamic mapping enabled থাকলে — নতুন field auto-add। কিন্তু wrong type-এ infer হতে পারে। Solution: explicit mapping template।
• Cache (Redis): JSON store — নতুন field harmless, ignore হবে। কিন্তু কোনো consumer যদি field absence assume করে — bug।
• Warehouse (Iceberg/Delta): এদের schema evolution native — নতুন column add হলে old data-তে NULL। কিন্তু column drop, type change — destructive change, careful migration লাগে।

Schema Registry — best practice:

• Avro/Protobuf serialization + Confluent Schema Registry।
• Compatibility mode: BACKWARD — নতুন schema পুরোনো consumer-এ deserialize করতে পারে। নতুন field-এর default value থাকতে হবে।
• FULL compatibility — দুদিকেই compatible। সবচেয়ে নিরাপদ।
• Producer (Debezium) Schema Registry-তে register; consumer fetch করে dynamic deserialize।

Breaking changes — কী করবেন:

• Column drop: deprecated mark করুন, ৩-৬ মাস wait, তারপর drop। Consumer-দের update করতে দিন।
• Type change (VARCHAR → INT): never in-place — নতুন column add, app dual-write, পুরোনো deprecate।
• Required new column: nullable হিসেবে add, default value, কোডে slowly mandatory।

Daraz-specific scenario:

• "discount_pct" নতুন column add হলো inventory table-এ।
• Debezium event-এ after.discount_pct immediately appear।
• Search team এই field index করতে চাইলে — Elasticsearch mapping update; reindex existing docs (কারণ পুরোনো event-এ ছিল না)।
• Cache → no-op, JSON ignore।
• Warehouse → Iceberg ALTER TABLE ADD COLUMN; পুরোনো partition-এ NULL।
• Analytics dashboard query-এ COALESCE(discount_pct, 0) defensive।

Communication & process:

• "Schema-as-code" repo — সব table definition Git-এ। Pull request দিয়ে যেকোনো DDL।
• Slack channel #cdc-schema-changes — DDL deploy-এর আগেই broadcast।
• Contract testing — consumer-গুলো sample CDC payload-এর বিরুদ্ধে CI-তে validate।

মূল উপলব্ধি: CDC একদিকে producer DB, অন্যদিকে diverse consumer-এর contract। Schema হলো সেই contract-এর ভাষা। Schema Registry + backward-compat + clear process — এই তিন ছাড়া CDC pipeline ৬ মাসে production নরকে পরিণত হবে। Tool যত ভালো হোক, governance ছাড়া অসম্ভব।

Microservice architecture-এ একটি classic problem — service local DB-তে data সংরক্ষণ করে এবং Kafka-তে event publish করে। দু'টি ভিন্ন system-এ atomic write কিভাবে?

Naive approach (broken):

// pseudo
db.save(order);          // step 1
kafka.publish(event);    // step 2

• Step 1 success, step 2 fail (network, broker down) → DB-তে order আছে কিন্তু event missing। Inventory adjust হলো না, customer-কে confirmation যায়নি।
• Step 1 success, step 2 success, কিন্তু crash before commit → duplicate event সম্ভব।
• "Two-phase commit (XA)" — distributed transaction — performance horrendous, ops nightmare, modern systems-এ rejected।

Outbox pattern:

• একই DB-তে একটি outbox table তৈরি।
• Order save এবং outbox-এ event row insert — দু'টোই একই DB transaction-এ → atomic।
• Debezium সেই outbox table-এ CDC বসায় → Kafka-তে event publish।
• Outbox row delete বা archive (idempotent flag)।

BEGIN;
  INSERT INTO orders (id, user, amount) VALUES (...);
  INSERT INTO outbox (event_type, payload, ts)
    VALUES ('OrderCreated', '{...}', now());
COMMIT;
-- Debezium captures the outbox INSERT, publishes to Kafka

কেন এটা bulletproof:

• Atomic: দু'টি write এক transaction-এ — হয় দু'টোই save, না হলে কোনোটাই না।
• Reliable delivery: Debezium binlog-এ outbox INSERT দেখলেই — Kafka-তে publish। Kafka temporarily down থাকলেও — later replay।
• Exactly-once: Debezium offset checkpoint + Kafka transactional sink → প্রতিটি outbox row ঠিক একবার Kafka-তে।
• No service code complexity: service শুধু একটা সাধারণ DB transaction লেখে। Kafka client, retry logic, circuit breaker — কিছুই দরকার নেই।

Bangladesh use case (bKash):

• Money send — transactions table-এ row + outbox-এ {type: TransferComplete, sender, receiver, amount}।
• Atomic commit।
• Debezium event Kafka topic bkash.outbox.transfer-এ যায়।
• Notification service event consume → SMS পাঠায়।
• Fraud service event consume → real-time score।
• Ledger service event consume → ledger DB-তে update।
• Service crash বা Kafka outage হলেও — outbox row binlog-এ আছে, Debezium recovery-এ replay।

Implementation tips:

• Outbox row-এ event_id UUID — consumer-এ idempotency check।
• Debezium OutboxEventRouter SMT — outbox row থেকে appropriate Kafka topic-এ route।
• Old outbox rows TTL/cleanup job — DB bloat avoid।
• Schema versioning event payload-এ — schema change সামাল।

Trade-offs:

• Latency: outbox INSERT → Debezium read → Kafka publish — সাধারণত ১-৫ সেকেন্ড। Sub-100ms চাইলে inadequate।
• Service-DB-Debezium ৩-component dependency — operational overhead।
• Outbox table যদি hot হয় — DB write amplification।

মূল উপলব্ধি: "Just send to Kafka after DB commit" simple-looking কিন্তু catastrophically broken at scale। Outbox pattern একটি database transaction-এর atomicity-কে distributed event delivery-র correctness-এ rope করে। বাংলাদেশ ও বিশ্বের সব serious microservice architecture (bKash, Pathao backend, Daraz checkout) এই pattern-এ চলে। CDC ছাড়া এই pattern impossible — তাই CDC শুধু analytics tool নয়, microservice-এর basic infrastructure।

Greenfield CDC সহজ; existing batch থেকে migration কঠিন। সাবধানতার সাথে phased rollout লাগবে — production কে কখনোই disrupt করা যাবে না।

Phase 0 — Discovery (২ সপ্তাহ):

• ১০০ table-এর ক্রমিক list — কোনটা PII, কোনটা high-volume, কোনটা rarely-changing।
• Downstream consumers map — কারা batch dump-এ depend। Risk team? Reporting? Marketing?
• Current batch SLA — সকাল ৬টার মধ্যে data warehouse-এ ready হতে হবে?
• DBA stakeholder interview — concerns, infrastructure (replica আছে?)।
• MySQL config check: binlog_format=ROW, binlog_row_image=FULL, retention যথেষ্ট কিনা।

Phase 1 — Infrastructure (৩-৪ সপ্তাহ):

• Kafka cluster setup (managed: AWS MSK, Confluent Cloud) বা self-host। ৩-broker minimum।
• Kafka Connect distributed cluster — ৩ worker।
• Schema Registry (Confluent বা Apicurio)।
• Monitoring: Prometheus + Grafana + Kafka Connect metrics + connector lag alerts।
• MySQL read-replica যদি না থাকে — production team-এর সাথে কাজ করে set up। CDC এই replica থেকে।
• Network/security: Kafka Connect → MySQL VPC peering, TLS, ACL।

Phase 2 — Pilot (৪-৬ সপ্তাহ):

• ৫টা low-risk table বাছুন — যেমন products, categories, policy_types। Volume মাঝারি, schema stable।
• Debezium connector deploy। Initial snapshot off-peak (রাত ২টা)।
• Kafka topic-এ event flow verify। Schema Registry-তে schema register।
• Sink consumer তৈরি — Iceberg-এ append/upsert। Existing batch parallel চালু থাকবে।
• Daily reconciliation: CDC-derived warehouse table vs batch-derived — count, sum, max(updated_at) match কিনা।
• ২ সপ্তাহ smooth চললে — Phase 3।

Phase 3 — Expansion (৮-১২ সপ্তাহ):

• Table-গুলো group-এ migrate (১০ table প্রতি সপ্তাহ)।
• High-volume / high-risk table (e.g., claims, payments) সবচেয়ে শেষে — সব lesson learned apply করার পর।
• Stakeholder communication — risk, marketing team-এ access bridge (CDC stream → আগের warehouse table-এর adapter)।
• Data quality framework — CDC-derived data-তে freshness, completeness, accuracy check।

Phase 4 — Cutover (২ সপ্তাহ):

• সব table CDC-তে migrate, ১ মাস dual-running।
• Reconciliation report — discrepancy <০.০১% হলে batch decommission।
• Old batch jobs disable, archive, document the change।
• Cost saving compute — DBA-কে দেখান (CFO-কে justify করার জন্য)।

Risk mitigation throughout:

• Rollback plan ready: connector pause + batch resume — ১৫ মিনিটের মধ্যে।
• On-call rotation Phase 2 থেকে।
• Documentation runbook: connector restart, snapshot trigger, lag alert response।
• Kafka retention conservative শুরুতে (৭ days), পরে কমান।

Common pitfalls:

• "সব table একসাথে migrate" — অসম্ভব। Connector load, schema issue, downstream surprise — হবেই।
• "Pilot skip করা" — production-এ first try কখনোই না।
• "Reconciliation skip করা" — silent data drift detect না হলে — ৩ মাস পর audit-এ ধরা পড়লে catastrophic।
• "Schema Registry skip করা" — short-term সহজ, long-term debt।
• "Stakeholder communicate না করা" — ML team batch table-এ depend করছে, একদিন তাদের না জানিয়ে cutover — trust ধ্বংস।

Timeline summary: ২০-২৪ সপ্তাহ (৫-৬ মাস) — সাবধানী, gradual। দ্রুত করতে চাইলে production accident certain।

Business case slide (CTO-কে):

• Latency: ১২ ঘণ্টা → ৩০ সেকেন্ড। Risk team realtime fraud, claims team near-real-time visibility।
• DB load: peak query 25% → 3%। DB infra scale-down possible।
• Reliability: batch failure (~মাসে ১-২ বার) → fault-tolerant streaming।
• Cost: ETL Hadoop cluster ($৩K/মাস) → Kafka + Connect ($১.৫K/মাস)।
• Future-proof: microservice eventing, real-time dashboard — সব unlocked।

মূল উপলব্ধি: CDC migration একটা technology project-এর চেয়ে বেশি — organizational change। Engineer-এর কাজ — risk-aware, communication-rich, gradual rollout। "Big bang" cutover-এ blast radius বড়; phased approach-এ each step revertible। Bangladesh-এর insurance/banking-এ এই discipline-ই প্রকৃত মূল্য আনে।