How does CDC differ from application-published domain events?

CDC (Change Data Capture) and application-published domain events both produce Kafka events from a database change, but they differ in three important ways: the source of truth, the coupling, and the meaning of the event. CDC reads the database's transaction log and emits events that describe the row-level changes: inserts, updates, and deletes, with the before and after values. The event is a low-level representation of the database state, not a business event. Application-published domain events are emitted by the application code and describe a business fact: OrderCreated, PaymentFailed, UserRegistered. The event is a high-level representation of what happened, and it is explicitly designed by the application. The source of truth for CDC is the database; for domain events, it is the application's domain model. The coupling for CDC is to the database schema; for domain events, it is to the application's event contract. The trade-off is between fidelity and meaning. CDC captures every change with perfect fidelity, including changes made by other applications or by direct SQL, but the events are not business-meaningful. Domain events are business-meaningful but only capture what the application chooses to publish, and they can miss changes made outside the application.

The mechanism of CDC is that a connector like Debezium reads the database's transaction log (WAL for PostgreSQL, binlog for MySQL, redo log for Oracle) and converts each change into a Kafka event. The event includes the operation type, the before and after values, and the transaction metadata. This means CDC captures changes regardless of how they were made: through the application, through a database tool, or through a batch job. It also means CDC is tightly coupled to the database schema: if a column is added, removed, or renamed, the CDC event changes, and consumers may break. The mechanism of application-published domain events is that the application code constructs the event and publishes it, often using the outbox pattern to avoid the dual-write problem. The event is decoupled from the database schema because the application maps its domain model to the event contract. This makes the event more stable and more meaningful, but it requires the application to publish every relevant change, and it can miss changes made outside the application. The trade-off is between completeness and stability. CDC is complete but brittle; domain events are stable but incomplete. Version note: many teams use both: CDC for data replication and integration with legacy systems, and domain events for business logic and downstream consumers. Debezium supports both patterns, and the outbox pattern is a way to combine them: the application writes domain events to an outbox table, and CDC publishes them.

A common mistake is to use CDC events as domain events. CDC events describe row changes, not business facts; a consumer that receives an update event does not know why the update happened or what business process it is part of. Another mistake is to assume that application-published events capture all changes. If someone updates the database directly, the application does not publish an event, and downstream consumers miss the change. A third mistake is to couple consumers to the CDC event format, which changes whenever the database schema changes. The trade-off is between simplicity and correctness. CDC is simpler because it requires no application changes, but it produces low-level events that are hard to consume. Domain events require application changes but produce high-level events that are easy to consume. For a new system, domain events are usually the right choice; for integrating with a legacy database that cannot be changed, CDC is often the only option. Version note: Debezium's outbox event router allows the application to write domain events to an outbox table, and CDC publishes them as domain events. This combines the consistency of CDC with the meaning of domain events, and it is the recommended pattern for new systems.