Debezium CDC vs application events¶

Сравнения · Раздел03

Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.

Версии указаны в заголовках и связанных статьях. Численные показатели производительности не заявляются.

Критерии выбора¶

Критерий	Debezium3.3 CDC	Application domain events / Outbox
Workload / architecture	Storage change capture и baseline replication	Explicit domain intent/history/integration contract
Consistency / transaction boundary	Connector snapshot/log protocol; delivery/replay scope	Atomic DB+outbox при правильной реализации; relay at-least-once
Latency path	Log mining/decoding, batches и source transaction delay	Application commit/outbox relay/broker path
Throughput / scalability	Source log/task limits и sink capacity	Owner write path/outbox indexes/relay capacity
Operational complexity / cost	Source privileges/log retention/schema history/connector ops	Application schema/contracts/outbox cleanup/consumer versioning

flowchart TB
  App[Business transaction] --> Tables[Operational tables]
  App --> Outbox[Atomic outbox intent]
  Tables --> CDC[Debezium storage-change capture]
  Outbox --> Relay[CDC or polling relay]
  CDC --> Projection[Current-state projection]
  Relay --> Domain[Domain integration event contract]

Конкретные сценарии¶

Legacy banking tables без изменения приложения → CDC projection с interpretation/reconciliation. PaymentPosted/BetResettled semantic contract → application event в outbox. Debezium может читать outbox: варианты сочетаются.

Ограничения и восстановление¶

CDC не Event Sourcing; snapshot op=r нельзя превращать в новый payout. Событие приложения без outbox может потеряться между DB commit и publish. Нужны owner/version/retention и payload semantics.

Как проверить выбор¶

Зафиксировать query/event mix, schema/payload, skew, working set/state, retention, target effect и допустимую stale-read policy. Проверять lost ACK, restart/rebalance, poison record, late correction и rebuild generation. Сравнивать TCO с одинаковыми durability/replication требованиями, включая engineering, maintenance и restore. Универсальный winner отсутствует.

Типичные ошибки проектирования¶

Сравнивать разные boundaries как одинаковую гарантию; игнорировать recovery и source retention; публиковать чужие latency/TPS как свои измерения; забывать target operations.

Вопросы на собеседовании¶

Когда стоит сочетать варианты? Когда они отвечают на разные уровни/нагрузки и contracts переходов определены. Дополнительный компонент добавляет ownership, lag, recovery и стоимость, поэтому нужна измеримая польза.

Практические упражнения¶

Составьте ADR для одного сценария: invariant, rejected alternative, failure matrix, recovery evidence и план честных измерений. Укажите, какие guarantees ещё UNKNOWN.