Which implementation reads directly from the transaction log?

Log-based CDC decodes committed changes from the transaction log.

Where is the publishable boundary in the shop?

The outbox record forms the deliberate contract; CDC transports it from the shared database to the hypothetical search projection.

When is direct CDC on business tables risky?

When internal schema changes, backfills, or deletions reach consumers without a stable external contract.

Standalone conceptMechanismChapter II · Data · Building block 16 of 16

Change Data Capture

CDC makes committed data changes available to downstream processing.

By Michael Meierhoff · Meierhoff Systems

Capture sourceDetermines which committed changes become visible and in what form.
PositionMarks the last safely processed point and controls restart and retention.
Schema contractGoverns meaning, versioning, and backfills independently of internal table changes.

Context

Why this is important

The architecture decision lies in the change feed and its operational guarantees, not merely in the connector product.

This profile covers CDC broadly and places log-based CDC as one implementation. The shop extension with connector and projection is hypothetical; the current shop has seven modules in one process and one shared database.

Shop example · Mapping

Compare CDC capture approaches

The current shop remains a modular monolith with seven modules—Catalog, Cart, Order, Payment, Inventory, Shipping, and Invoice—and one shared database. For a hypothetical search projection, Order writes a business change and an outbox record atomically. A log-based CDC connector reads the committed outbox record, publishes it, and stores its position. The team stops the connector after publication, restarts it, and tests duplicate handling, lag, and schema evolution before adopting this distributed extension.

This is how you read the picture

Capture source Log, trigger, change table, or managed feed
Position Acknowledge the offset only after a successful effect
Schema contract Check compatibility before connector rollout

Compare CDC capture approaches
Comparison	Capture	Strength	Critical boundary
Log-based	Decode the database log	Low query overhead and commit-near ordering	Log access, retention, and internal schema
Trigger/change table	Record the change during the write	Explicit selection and extra metadata are possible	Write path, trigger maintenance, and table growth
Timestamp polling	Query changed rows repeatedly	Simple start without log access	Gaps, deletions, load, and polling latency

The capture source changes coupling, latency, and operational ownership.

Benefits & limitations

Helps if:

CDC fits when several downstream views need timely updates from committed data changes.
Log-based CDC fits when the database exposes a stable change feed and extra queries or triggers should be avoided.
An outbox plus CDC fits when the published contract must be separated deliberately from internal table changes.

Boundaries

Internal table changes rarely form a stable integration contract without an outbox; renames and backfills must be coordinated with consumers.
Replication slots or equivalent positions can retain logs; growing lag threatens storage and recovery.
CDC delivers changes but not exactly-once business effects. Consumers need idempotency, correlation, and tested recovery.

In practice

Commit an order and outbox row in the shared shop database, then compare the business row, outbox entry, and published event. Identify exactly which observation came from the transaction log.
Interrupt the relay after it reads a log entry and restart it. Check that it resumes from the correct log position and that redelivery remains idempotent at the consumer.
Compare polling the outbox with CDC by latency, database load, and schema evolution. Decide which operational responsibility the team can own and how it will prove backlog recovery.

Read the detailed explanation

CDC observes durable changes after commit and translates them into a stream consumers can read. With log-based CDC, a connector decodes the transaction log; other variants read change tables, trigger output, or database change feeds.

The contract covers more than payloads: table or topic selection, ordering within a partition, start position, retention, schema evolution, and restart behavior. A committed offset prevents data loss but a crash between effect and acknowledgement can still cause redelivery.

Transactional Outbox creates publishable messages in the same transaction as the business change. Idempotency limits the effect of redelivery. CDC can transport an outbox, but it also supports replication, search, and analytical projections.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
Which implementation reads directly from the transaction log?
View the solution with justification
Log-based CDC decodes committed changes from the transaction log.
ApplyingTransferred to a new situation
Where is the publishable boundary in the shop?
View the solution with justification
The outbox record forms the deliberate contract; CDC transports it from the shared database to the hypothetical search projection.
EvaluateWeighing an alternative
When is direct CDC on business tables risky?
View the solution with justification
When internal schema changes, backfills, or deletions reach consumers without a stable external contract.

Explore further

These building blocks continue the thoughts of this page.

References

Continue on the learning path

With that, you have Data & state run through. It continues with Communication & APIs.

16 Building blocks

Next areaCommunication & APIs