02 / Event source · Change data capture
Keep the database.
Let changes travel.
Database Write Through
Use committed database changes to inform downstream systems while retaining the application's existing write boundary.
The database remains the write boundary
Applications keep writing to the database. Committed changes become input to downstream systems.
Presentation: ← → to step · Esc to exit
01 / Problem
The change is trapped.
A database records the new state, but other systems need to react. Separate application writes to a database and a broker can leave the two out of sync when one fails.
02 / How it works
Follow committed changes.
A CDC connector captures inserts, updates and deletes and publishes change events. A consumer applies them to a downstream projection. The row key can keep related records in the same stream partition.
03 / Why use it
Extend an existing boundary.
CDC can make existing data available to event-driven consumers without adding a broker write to each application transaction. Database changes describe storage mutations; meaningful business events may require additional interpretation.
04 / Trade-offs
Delivery needs a contract.
Capture and processing introduce lag. Delivery guarantees depend on the connector and configuration; consumers should handle retries idempotently. A CDC delete envelope can be followed by a null-value Kafka tombstone for compaction. These are distinct records, not universal delete semantics.
Technical reference: Confluent — Database Write Through. All operations are local simulations.