Change Data Capture (CDC)

Change Data Capture turns a database into a source of events. Rather than polling tables or modifying every write path, CDC observes the changes themselves and emits an event for each insert, update, and delete. It lets other systems react to data changes in near real time without coupling to the application that made them.

How It Works

The most robust form of CDC reads the database's transaction log (the write-ahead or binary log), which records every committed change in order. A connector tails this log and translates each entry into a structured change event, then publishes it to a stream such as Kafka. Because it reads the log rather than the tables, log-based CDC is low-impact and captures every change including deletes, in commit order.

Simpler variants use timestamps, version columns, or triggers, but these are more intrusive and can miss deletes. Debezium is a widely used log-based CDC platform.

CDC events typically include the operation type, the changed columns, and often both the before and after images of the row, which lets consumers compute deltas. Snapshotting is used to load existing data before streaming new changes, so a downstream system can be initialized and then kept current from the same pipeline. Schema-change events are emitted too, allowing consumers to evolve alongside the source.

When to Use It

Use CDC to replicate data between systems, to feed data warehouses, caches, or search indexes, to build CQRS read models, and to relay a transactional outbox reliably. It excels whenever downstream systems must stay synchronized with a database without changing the source application.

If you fully control writes and can publish events in code, an outbox written by the application may be simpler than capturing changes externally.

It is also a low-risk way to integrate with a system you do not own or cannot modify, since capturing its changes requires no cooperation from the application that writes them.

Trade-offs

Log-based CDC requires access to and understanding of the database's internal log format, which differs per engine and can break on upgrades. There is replication lag between the change and the event. Schema changes must be handled carefully. The connector is critical infrastructure that needs monitoring. The payoff is decoupled, complete, low-impact change streaming. Because the connector position in the log is itself critical state, teams persist and monitor that offset carefully, since losing it can mean either reprocessing history or silently skipping changes.

Related Patterns

CDC is the preferred relay for the Transactional Outbox. It feeds CQRS read models and is conceptually adjacent to Event Sourcing. It supports the Database per Service model by syncing data without shared access.

Example

A company wants its search index to reflect catalog edits within seconds. A Debezium connector tails the PostgreSQL write-ahead log of the catalog database. Each product update becomes a Kafka event consumed by an indexer that updates Elasticsearch. The catalog application is unchanged and unaware, yet search stays current and other consumers (analytics, cache invalidation) can subscribe to the same stream.