Change Data Capture — One Leader, Many Derived Followers (Figure 12-5) Diagram

Concurrent writes may reach the database in any order, but the database decides the order in which they commit
Every committed write is appended to the replication log in that order, so the log fixes one total order of writes
A CDC connector tails the log and emits a change event per write, preserving the commit order downstream
A log-based broker transports the events without reordering them, and every derived system applies them in that same order
The search index, cache, and data warehouse are simply followers of the one leader database

A new derived system needs the whole dataset, not only recent changes, so the change log alone is not enough
Take a consistent snapshot of the database at a known offset in the change log, then apply changes starting from that offset
Debezium provides incremental snapshots using Netflix's DBLog watermarking algorithm
Log compaction is an alternative: the topic keeps only the most recent value per key, so a new consumer can scan it from offset 0 for a full copy
With compaction the broker doubles as durable storage, so no second snapshot of the source database is needed

Replicating the internal database schema via CDC turns that schema into a public API that downstream consumers depend on
An outbox table has its own stable schema, and CDC replicates the outbox instead of the internal domain model
The application writes the domain row and the outbox row in one transaction: a dual write kept inside one system
Internal schemas can then evolve freely while the outbox tables stay untouched for consumers
Trade-offs: maintaining the transformation between the two schemas, and extra write volume in the database