Queues, Streams, Eventing
Change data capture: multiple-choice review
Crux Multiple-choice synthesis across the CDC unit — replication-slot risk, WAL retention, snapshot strategy, delete capture, delivery semantics, and ordering.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a decision you make running CDC in production — not a definition to recite, but a failure mode to reason about before it pages you.
Goal
Confirm you can connect the slot mechanism, WAL retention, snapshot strategy, delete capture, and delivery semantics — the synthesis the lesson built toward.
Quiz
Completed
A Debezium connector's Kafka Connect worker OOMs and stays down for six hours on a busy OLTP box. What is the dominant risk to the source Postgres, and why?
Heads-up Events are not lost — the slot holds the WAL precisely so the connector can resume from its LSN. The danger is the opposite: retained WAL grows until the disk fills.
Heads-up A logical slot persists across disconnects by design — that persistence is the whole point and exactly why it is dangerous. Postgres only invalidates it if max_slot_wal_keep_size is set and exceeded.
Heads-up Postgres keeps accepting writes — that is what grows the WAL. It only stops when the disk is actually full.
Quiz
Completed
Your CDC connector looks completely healthy — consuming, lag near zero — yet WAL on the primary keeps climbing and the disk is filling. What is the most likely cause?
Heads-up A re-snapshot reads existing rows; it does not pin WAL upward on its own. A frozen restart_lsn from an open transaction is the classic cause of growth with a healthy-looking connector.
Heads-up A slot does not increase WAL generation — it only controls how long segments are retained. Retention only grows the disk when something stops the confirmed position from advancing.
Heads-up Kafka back-pressure can stall the consumer (which would show as lag), but it does not change how Postgres writes WAL. The give-away here is that lag is near zero — pointing at a frozen restart_lsn.
Quiz
Completed
You must bootstrap CDC on a multi-terabyte MySQL table that takes constant writes, and you cannot freeze writes for hours. Which snapshot strategy fits, and what is the tradeoff?
Heads-up A blocking snapshot (FLUSH TABLES WITH READ LOCK) is exactly what freezes writes on a large table for an uncomfortable window — the thing the brief forbids on a multi-terabyte table.
Heads-up The log only contains recent changes, not the current state of every existing row. Skipping the snapshot leaves downstream consumers missing all rows that were not modified after start.
Heads-up A timestamp is not a replication position; you cannot reliably align a logical dump to an exact binlog offset, so you risk a gap or overlap at the seam. The incremental snapshot exists to align snapshot and stream cleanly.
Quiz
Completed
A Postgres DELETE event arrives with a before image that contains only the primary key, but your downstream needs the full pre-delete row. What is going on, and what is the cost of the fix?
Heads-up Debezium emits exactly what the WAL contains for that table. The before image is key-only because of REPLICA IDENTITY, not a connector size limit.
Heads-up Vacuum reclaims dead tuples but does not control what the WAL logs for a DELETE. The pre-delete image is governed by REPLICA IDENTITY, set per table.
Heads-up A tombstone is a null-value record after a delete that lets compacted Kafka topics drop the key — it carries no row data. The full before image comes from REPLICA IDENTITY FULL.
Quiz
Completed
Your team says 'Debezium 2.x gives exactly-once, so our consumer can skip dedupe.' Where does that reasoning break?
Heads-up The guarantee ends at Kafka. On resume from the last confirmed LSN the connector may re-emit events, and a consumer crash between read and commit reprocesses — so duplicates are still possible downstream.
Heads-up Debezium tracks offsets precisely via the slot/LSN — that is how it resumes. Precise resume is exactly what can cause a replay of events after the confirmed point.
Heads-up Cross-partition ordering is a separate concern. The reason you still need idempotency is duplicate delivery on resume, independent of ordering.
Quiz
Completed
A consumer joins changes from an orders table and a payments table and assumes it sees them in commit order. Under Debezium-to-Kafka, why is that assumption unsafe?
Heads-up Kafka guarantees order within a partition. The problem is that the two tables/keys land in different partitions, where no cross-partition order is promised.
Heads-up There is no global commit-ordered stream across partitions. Order is per-key only; a cross-table join cannot rely on commit order.
Heads-up REPLICA IDENTITY controls what a delete logs, not ordering. Cross-table ordering is a partitioning property, unrelated to identity.
Recap
Across the unit the through-line is one chain of consequences: the slot’s unconditional WAL promise is what makes CDC resumable and also what fills the disk when a consumer stalls or a long transaction freezes restart_lsn; bootstrapping means snapshot-then-stream, with incremental snapshots trading simplicity for a lock-free start; capturing full deletes costs WAL volume via REPLICA IDENTITY FULL; and because resume is at-least-once with only per-key ordering, consumers must be idempotent and must not assume global commit order.