Change Data Capture

The Insight

 every committed transaction is ALREADY recorded, ordered,
 and durable — in the database's own log (WAL/binlog):

 [WAL] BEGIN; INSERT order-42; UPDATE stock; COMMIT;
       BEGIN; INSERT order-43; ...            COMMIT;

 CDC = tap that log and stream it as events:

 [postgres WAL] ──► [debezium-class connector] ──► kafka topic
                                                    │
                                     consumers see row-changes
                                     as structured events ✓

 no application changes. can't forget an event.
 the database IS already a perfect producer.

What CDC Events Carry

 per change: before/after images + metadata:

 {op: "update",
  source: {table: "orders", lsn: 881234},
  before: {id:42, status:"PENDING"},
  after:  {id:42, status:"PAID"},
  ts_ms: ...}

 patterns:
 - ROW IMAGES: full state → naturally idempotent consumers ✓
 - DELTAS only (some setups): replay-dangerous; prefer images
 - FILTERING/FLATTENING at connector or downstream processor:
   raw rows → domain events ("OrderPaid") via a transformer stage

The Use Case Map

Use case	How CDC serves it
Cache invalidation	changed rows → purge keys
Search indexing	changes → elasticsearch upserts
Read-model sync	CQRS projections without app code
Audit streams	every change captured natively
Cache/warehouse ETL	continuous instead of nightly batches
Outbox delivery	tail outbox TABLE specifically

 meta-point: CDC replaces a whole class of fragile
 "remember to publish" application code with infrastructure.

Operational Realities

 □ LOG RETENTION: consumer down longer than log retention =
   unrecoverable position → resync needed. monitor lag hard!
 □ SCHEMA CHANGES: ALTER TABLE flows through as events;
   connectors/consumers must handle schema evolution
   (registry integration helps)
 □ SOURCE LOAD: reading WAL is cheap but not free;
   snapshot initial-load for big tables needs throttling
 □ EXACTLY THE SAME RULES APPLY: at-least-once delivery,
   idempotent consumers, per-key ordering (primary key!)
   CDC doesn't repeal distributed-systems laws.

CDC vs Outbox

 both solve dual-write via the log:

 OUTBOX-CDC: tail the outbox table → clean DOMAIN events,
             explicit control of payload shape ✓
 TABLE-CDC:  tail business tables → zero app code, but
             events are row-shaped, schema-coupled

 common production shape: table-CDC into a transformer
 that emits domain events downstream.
 start with whichever your team can operate confidently.

Interview Framing

“Sync Postgres orders into Elasticsearch with <5s staleness” scored answer: CDC as THE mechanism (not nightly jobs, not app-level double-writes), connector architecture sketched, idempotent-upsert consumers, log-retention/lag caveat named, schema-evolution mentioned. Recognizing “this is a CDC problem” from requirements phrasing (“<N s staleness”, “keep in sync”) is the tested skill.