Three teams need to know when an order changes. The usual answers all share one flaw.
Polling asks every thirty seconds and misses any change that does not survive that long. Dual writes — write to the database, then write to the other system — break the moment one of the two fails. The outbox pattern works well, and depends on every writer remembering to use it.
Meanwhile the database has been keeping a perfect, ordered record of every committed change the whole time. Change data capture reads it.
A connector tails the write-ahead log and turns each committed change into an event on a durable, ordered stream. Application code changes not at all. One stream then serves a search index, cache invalidation, analytics and an audit trail, each consumer reading at its own pace.
What we still own is the awkward part. The events carry the database's shape rather than the domain's — row 8842 changed instead of order shipped. Consumers must handle duplicates and replay. Ordering holds per partition rather than globally. And reliability now rests on log retention and connector health.
Before building a new source of truth, it is worth checking whether something is already recording it faithfully.