Log-Based CDC
Capturing changes by reading the database's own write-ahead log, which sees every change with no load on the source and no application involvement.
The connector reads the replication log the database already produces for its own replicas — Postgres logical decoding, MySQL binlog, Oracle redo logs — and emits an event per row change. Debezium is the common implementation.
Its advantages over the alternatives are decisive where it is available. It captures every intermediate state, including deletes, which polling cannot. It imposes almost no load on the source, because the log is being written regardless. It requires no schema change and no application change, which is what makes it viable against systems that cannot be modified. And it carries transaction boundaries and ordering.
The operational realities. The connector's log position is critical state — lose it and you must re-snapshot. If the connector is down long enough for the source to recycle its logs, the position is unrecoverable and a full snapshot is required, so log retention on the source must be sized for the worst plausible outage. It needs elevated database privileges. And schema changes flow through as events that downstream consumers must tolerate.
The important architectural caveat: CDC events are database events carrying table and column names. Publishing them directly couples every consumer to the source schema — treat them as an internal feed to be translated into business events, not as the published contract.