Change Data Capture (CDC) & Debezium

In distributed architectures, applications frequently need to update multiple storage systems simultaneously—for example, persisting an order to PostgreSQL, updating a search index in Elasticsearch, and evicting a stale cache entry in Redis.

The intuitive, naive approach is Application-Level Dual-Writing:

typescript
Copy
async function createOrder(orderData) {
  // Write 1: Database
  await db.orders.insert(orderData);
  // Write 2: Elasticsearch
  await elasticsearch.index({ index: 'orders', document: orderData });
  // Write 3: Redis Cache
  await redis.del(`user:${orderData.userId}:orders`);
}

Why Dual-Writing Inevitably Fails:

1. Partial Failures & Network Partitions: If Write 1 succeeds but Write 2 fails due to a network timeout, the application crashes or throws an error. The search index is now permanently out of sync with the database unless complex distributed 2-Phase Commit (2PC) is implemented.
2. Race Conditions & Lost Updates: If two application instances simultaneously execute writes to the same record in opposite order (Instance A: v_1 → v_2, Instance B: v_2 → v_1), the database and Elasticsearch may end up storing conflicting states permanently.