Problem
Downstream systems (search, analytics, cache, replicas) need database changes. Polling is slow; dual-write is unreliable.
data-consistencyestablished · high operational burden
Change Data Capture (CDC)
Also known as: cdc-pattern, debezium, log-based-cdc
Intent
Capture database changes (insert/update/delete) in real-time and stream them to downstream systems.
Forces
- •Multiple consumers need database changes
- •Must not impact primary database performance
- •Changes must be captured in order, exactly once
- •Schema changes must be handled gracefully
Solution
✓ When to Use
- •Real-time analytics, search indexing, cache invalidation
- •Event sourcing / CQRS projection updates
- •Audit logging, compliance
- •Cross-database synchronization
✗ When Not to Use
- •Low change volume (polling simpler)
- •Database doesn't support logical replication
- •Team not ready for streaming infrastructure
Pros
- +Zero application code changes
- +Complete, ordered change stream
- +Low overhead on primary (log reading)
- +Multiple consumers from single capture
Cons
- −Operational complexity: connectors, schema registry, Kafka
- −Schema evolution: upstream changes break downstream
- −Large transactions: memory pressure, latency
- −DDL handling: requires coordination
Cost Profile
Infrastructure
Medium — Kafka cluster, Connect workers, schema registry
Operational
High — connector monitoring, schema evolution, rebalancing
Cognitive
Medium — event modeling, schema design
Failure Modes
Connector lag → stale downstream
Schema change breaks consumer → data loss
Large transaction OOMs connector
Kafka outage → backlog, replay on recovery
DDL not captured → silent data loss
Real-World Examples
Alternatives
- outbox-pattern
- polling
- triggers
- dual-write
Related Patterns
- outbox-pattern
- event-sourcing
- cqrs
- materialized-view
- data-sync
Competency Domains
data statedistribution communicationreliability opseconomics evolution