Change data capture (CDC) reads a database's own change log and turns every committed insert, update and delete into a stream of events, usually into Kafka. Examples of change logs are the Postgres write-ahead log (WAL) and the MySQL binlog. Debezium is a common tool for this.
CDC reads only committed changes from the log. So it captures every change in commit order, and the application does not need a second write. It also adds little load compared with polling queries.
Uses:
- Relaying a transactional outbox table to a message broker.
- Keeping caches and search indexes in sync with the database.
- Feeding analytics and data warehouses.
- Moving data while you split a monolith step by step (the strangler pattern).
One caution: raw table changes expose your internal schema. If you publish them directly as public events, consumers become tied to your tables, and you cannot change your tables freely. So for public events, prefer CDC on an outbox table with events you designed on purpose.
- CDC reads the database transaction log, such as the Postgres WAL or the MySQL binlog.
- It captures committed changes in order, without a dual write.
- It feeds outbox relays, caches, search indexes and analytics.
- Raw table events leak your internal schema to consumers.
- For public events, prefer CDC over an outbox table.