Change data capture (CDC)
A live feed of committed inserts, updates, and deletes, usually read from the database log instead of polling tables.
See it
What it is
Change data capture, usually shortened to CDC, reads committed inserts, updates, and deletes from a database and publishes them as an ordered change feed. Log-based tools such as Debezium read PostgreSQL's write-ahead log or MySQL's binlog, so applications do not need to poll every table or add a trigger to every write path.
Reach for it to keep a search index, cache, warehouse, or another service in sync with the database. It is especially useful when many writers change the same tables because the log sees their committed results in one place. An initial snapshot usually establishes the starting state, then the stream carries later changes.
Gotcha: CDC is normally at-least-once delivery, so consumers must survive duplicates and restarts. Ordering may hold only within a table, key, or Kafka partition, and schema changes need coordinated handling. CDC also reports that a row changed, not why the business changed it. Use a transactional outbox when downstream code needs a deliberate business event such as OrderPlaced rather than a raw row update.
Ask AI for it
Configure a Debezium PostgreSQL connector in Kafka Connect to stream the orders table. Use plugin.name=pgoutput, a dedicated slot.name, publication.autocreate.mode=filtered, and table.include.list restricted to the required tables. Run the initial snapshot, key Kafka records by the table's primary key, and write an idempotent consumer that handles Debezium op values r, c, u, and d plus delete tombstones. Store the last processed event identity with the projection update, expose connector lag and failed-record metrics, and test restart, duplicate delivery, delete, and compatible schema-change cases.