CDC (Change Data Capture)
Streams row-level database changes to downstream systems — search indexes, warehouses, caches — without dual-write bugs.
Interview tip Lead with a 30-second definition, then one real system example and name 2–3 designs where CDC (Change Data Capture) is non-negotiable.
① What it is (30 seconds)
Streams row-level database changes to downstream systems — search indexes, warehouses, caches — without dual-write bugs.
② How it works in system design
Read DB transaction log (Debezium, Maxwell). Emit insert/update/delete events to Kafka. Consumers update Elasticsearch, Redis, analytics. Ordering per primary key.
Typical placement
Client→Edge / Gateway→CDC→Services→Data stores
③ Concrete system design example
Scenario: Product catalog: PostgreSQL is source of truth. CDC stream updates Elasticsearch for search and Redis for featured products — no app-level double write.
④ Important interview Q&A
| Question | Answer |
|---|---|
| CDC vs application events? | CDC captures all DB changes including admin fixes; domain events only what app publishes. |
| Lag handling? | Monitor consumer lag; scale consumers; idempotent upsert in search index. |
| Deletes? | CDC tombstone events must delete from search index too. |
⑤ Seen in these system designs
- Gmail Search — index sync
- Distributed Search — index pipeline
- Google Analytics — event pipelines
In interviews, after explaining the concept, say: "This shows up directly in …" and link two designs.
⑥ Revision checklist
- Log-based CDC
- Ordering per key
- Delete handling
- Lag monitoring
- vs dual write