Change Data Capture (CDC)

Change Data Capture turns a database's own internal record of what changed into a stream of events other systems can react to — without the application ever having to explicitly publish anything. Every row insert, update, and delete is captured as it happens and emitted as an event, so downstream systems (a search index, a cache, a data warehouse, another service entirely) can stay in sync with the database in near real time.

Where the events actually come from

Every ACID Transaction a database commits is first written to a durable write-ahead log — the same log covered in that lesson as the mechanism behind durability, and the same one Data Replication streams to followers to keep them in sync. CDC works by tailing that exact same log: a CDC connector reads the stream of committed changes the database was already producing for its own replication purposes, and re-emits each one as a structured event (typically onto a message queue or a pub/sub topic) for anything else to consume.

System Design Lab

Why not just have the application publish events itself?

The obvious alternative — have application code publish an event every time it writes to the database — works, but it has a real correctness gap: the database write and the event publish are now two separate operations, and if the process crashes between them (or the publish itself fails), the database changes but no event goes out, silently desynchronizing every downstream consumer. CDC avoids this entirely by deriving events from what the database actually, definitely committed, rather than from application code's side-channel promise to also publish one. This makes the database the single source of truth for both the data and the fact that it changed, instead of relying on every write path in the application to remember to publish consistently.

What CDC is used for

• Cache invalidation — instead of application code remembering to invalidate a cache entry on every write path that might affect it (easy to miss one), a CDC stream can trigger invalidation directly off the database's actual change log, catching every write regardless of which code path made it.
• Keeping a search index in sync — a search index (a fundamentally different database type than the primary store) needs to reflect the same underlying data; CDC streams changes into it without the application needing to write to two systems on every request.
• Feeding a data warehouse or analytics pipeline — replicating operational data into an analytical store continuously, instead of slow, disruptive nightly batch exports.
• Decoupling a legacy system — CDC can expose a legacy database's changes as a modern event stream without touching the legacy application's code at all, which is often the only realistic way to integrate with a system nobody wants to risk modifying directly.

The tradeoff: eventual, not immediate

CDC events are inherently a little behind the write they describe — there's a real, if usually small, lag between a transaction committing and its event reaching a downstream consumer. Systems built on CDC are accepting eventual consistency for every downstream copy of the data by design, in exchange for not coupling the original write path to every consumer's availability and speed. That's a very different guarantee from a write-through cache updating synchronously in the same request — CDC trades immediacy for not making the primary write path depend on how many downstream systems are listening, or how fast they are.

Why this matters in an interview

CDC is a strong, specific answer whenever a design needs to keep a secondary system (cache, search index, warehouse) in sync with a primary database without coupling every write path to updating both — naming "we'll stream changes via CDC off the database's write-ahead log" is considerably more precise than "we'll keep them in sync somehow," and it demonstrates the write-ahead-log connection back to how databases actually guarantee durability and replication in the first place.

CDC vs. application-level dual writes: pros and cons

Pros

• ✓Derives events from what actually committed — no risk of a missed or failed publish
• ✓Catches every write path automatically, including ones a developer forgot to instrument
• ✓Decouples the primary write path from how many downstream consumers exist, or how fast they are

Cons

• ✕Introduces real lag between a write and downstream systems observing it
• ✕Requires operational access to the database's internal log, which not every managed database exposes
• ✕Adds a CDC connector as a new piece of infrastructure to run, monitor, and keep compatible with schema changes

Further Reading

• Debezium Documentation — What is Change Data Capture? — a concrete, widely used open-source CDC implementation's own explanation of the pattern.
• Confluent — Change Data Capture — a clear overview of CDC's use cases and how it integrates with event streaming platforms.