Comparison
Change data capturevsTransactional outbox
Change data capture
instead of asking the service to publish events, you read the database's own replication log and turn every row change into one.
Deriving a stream of change events from a database's write-ahead log. It guarantees you see every committed change with no application cooperation, which is why it is the standard way to get data out of a legacy system. The events are row-shaped rather than domain-shaped, so consumers end up coupled to the producer's schema.
Full entry →Transactional outbox
you write the row and the event to publish into the same database transaction, so you can never commit one without the other.
Persisting outbound messages in a table within the same transaction as the state change, then having a separate process publish them. It closes the dual-write gap where a commit succeeds and the broker publish fails, or vice versa. The publisher is at-least-once by nature, so consumers still need to deduplicate.
Full entry →