Change Data Capture Interview Questions: Log-Based Replication, Ordering, and Backfills

Change data capture interview questions test whether you can turn database changes into a trustworthy downstream stream. A strong answer distinguishes log-based capture from polling or triggers, explains transaction and key ordering, handles snapshots and backfills, and names what happens during connector or consumer failure. Debezium's documentation is a useful anchor because it describes row-level change events, connector offsets, snapshots, and source-specific behavior. The interview is less about reciting a product and more about defining correctness at every boundary.

Quick answer

Question	What the evidence supports	Practical move
Why log-based CDC?	It reads a database's change log rather than repeatedly querying current rows, preserving information that polling can miss.	State the source log, offset, and retention assumptions.
What does ordering mean?	Order can be guaranteed per partition, key, table, transaction, or database—not automatically everywhere.	Name the scope of the guarantee.
How do snapshots fit?	A snapshot establishes historical state before or alongside live changes.	Explain the handoff and duplicate handling.
What is a backfill?	A backfill repairs or populates historical data without losing newer changes.	Design a watermark and idempotent sink.
What is the first failure question?	Where can an event be duplicated, delayed, reordered, or lost?	Define replay and reconciliation before discussing scale.

Read this article in three layers. An official provider or employer source establishes what the product or process says. A candidate report can suggest a useful preparation drill, but it does not prove that every candidate sees the same configuration. The final layer is an inference: a tactic that follows from the evidence. Keeping those layers separate prevents a familiar platform name from turning into an invented universal rule.

Choose the capture boundary

Polling sees the current row and can miss intermediate updates or deletes unless the source exposes a reliable version. Triggers can write an outbox but add transaction coupling and operational work. Log-based CDC reads the database's committed change stream and can preserve operation type, transaction metadata, and source position. Debezium describes row-level change events and connectors for systems such as MySQL binlogs and PostgreSQL logical replication. A good interview answer chooses the boundary based on the required freshness, source support, and recovery model.

Ordering and identity

Do not say 'CDC is ordered' without naming the scope. A single log partition may preserve order, while multiple partitions can interleave events. A transaction can contain several row changes, and a downstream consumer may need transaction metadata to apply them atomically or to tolerate partial visibility. Use a stable event ID, source LSN or binlog position, table key, and operation timestamp. If the sink is partitioned by key, explain what happens when a key is re-partitioned or a transaction spans partitions.

Snapshots, offsets, and the live handoff

A connector often needs to copy existing rows and then continue from a log position. If the snapshot and stream overlap, the sink must be idempotent or deduplicate by source identity. If the connector crashes, its offset must be committed only after the downstream write is safe to replay. Ask what happens when the source log retention expires before the connector catches up. A production answer includes a resnapshot or reconciliation path, not just a happy-path diagram.

Backfills without overwriting fresh data

A backfill should carry a source timestamp, version, or watermark so the sink can reject stale writes. One pattern reads historical rows into a side stream, then merges them with live events by key and version. Another pauses consumption, but that increases lag and retention pressure. Make the choice explicit. Test deletes, tombstones, schema changes, and a row updated while its historical copy is in flight. The core invariant is that the sink converges to the source state without losing a committed change.

Schema evolution and contracts

A column addition is different from a rename, type narrowing, or semantic change. Include the schema version in the event, define compatibility rules, and make consumers tolerate fields they do not understand. A CDC pipeline should expose lag, source-log position, failed records, dead-letter volume, and schema errors. A replay tool must know which schema version to use. Saying 'we use Kafka' is not a schema strategy; the interview expects the contract around it.

Failure diagnosis and reconciliation

When counts disagree, compare source position, connector lag, sink commit, and a sampled key set. Distinguish duplicates from missing events and late arrivals from permanently lost data. Keep a replayable raw log or archive when the business impact justifies it. The final design should state whether delivery is at-least-once, exactly-once within a boundary, or effectively-once through idempotent writes. Be precise: exactly-once end to end is a property of the whole system, not a checkbox on the connector.

A focused preparation and recovery plan

Step	What to do	Evidence to keep
1. Confirm	Read the invitation, role page, or assessment landing page. Record the deadline, timezone, timer, allowed tools, identity checks, and accommodation contact.	A screenshot or saved message with private details redacted.
2. Baseline	Complete one representative exercise without changing the rules. Measure correctness, time, and the point where you became uncertain.	The prompt, your approach, and a short error log.
3. Diagnose	Separate a content problem from a platform, network, account, or evidence problem. Do not refresh repeatedly while a timer is running.	Timestamped notes, browser version, and visible error text.
4. Rehearse	Repeat the narrow skill this article identifies. Add one adversarial case and one explanation of what would change at larger scale.	A corrected solution or one-page decision record.
5. Escalate	If the official owner must change a deadline, reopen a session, or explain a report, send a concise factual request.	The original invite, incident timeline, and requested remedy.

Frequently asked questions

How does Debezium preserve CDC order?

Debezium documents ordered change events within its event streams, but the application must still define partition, transaction, and cross-table ordering semantics.

How do you avoid duplicate CDC writes?

Use a stable source position or event identity, idempotent upserts, and a sink commit protocol that is safe to replay.

What happens when a connector falls behind?

Monitor lag and log retention; resnapshot or reconcile before the source discards the required position.

How do you backfill while writes continue?

Use a watermark or versioned merge so historical rows cannot overwrite newer live changes.

What is a strong CDC interview answer?

Name the contract, show the failure path, and explain how you prove convergence after replay.

Before you start

Turn the article into a small decision record before you act. Write the exact question you need to answer, the source that could answer it, and the consequence of being wrong. For an assessment, that might be whether the timer stops, whether a second display is allowed, or whether a previous result can be reused. For a technical interview, it might be whether the system promises per-key ordering, whether the verifier can prove a loop is bounded, or whether a cache update can be replayed. This framing keeps preparation tied to the target rather than to a list of fashionable keywords.

Next, separate hard constraints from choices. A deadline, access rule, memory limit, privacy boundary, or source-of-truth requirement is a constraint. A page size, data structure, model pair, retry policy, or practice order is a choice that you should justify. Write one default choice, one alternative, and the signal that would make you switch. Interviewers and recruiters can then see judgment instead of a memorized answer.

Finally, decide what evidence will close the loop. Save a confirmation, a source position, a benchmark row, a test result, a metric, or a recovery ticket. Do not collect private assessment content or credentials. The evidence should be sufficient for the next person to reproduce the decision without exposing information they are not authorized to see. If the evidence is missing, label the conclusion provisional and ask the owner for the exact next action. That discipline is useful whether the page is about a hiring platform, a production system, or a candidate-reported study.

A final quality check is simple: remove any claim that depends on an unnamed company policy, an undated forum anecdote, or a number whose denominator you cannot explain. Replace it with the narrower fact, the verification step, or the limitation. Readers usually need a safe next move more than a confident-sounding prediction. That editorial boundary also makes the draft easier to update when a platform changes its controls or a new hiring cycle starts. Use the same discipline for every source and every handoff.

How to decide what to trust

The live invitation and the instructions shown inside the assessment outrank a generic article. The provider's current help center explains default product behavior, but employers can choose different question types, timers, proctoring controls, report fields, or deadlines. An official employer page establishes the published role or event context; it does not establish every team's interview sequence. Candidate reports are useful when they identify the role, date, and product, yet they remain samples. When two sources disagree, record the conflict instead of averaging it into a made-up number. If a technical incident is involved, preserve the state first, then use the platform's support route or the recruiter who owns the invitation. This approach is slower than guessing, but it gives the reader an action that can be defended and repeated.

Final takeaway

Lead with the CDC contract: what counts as a change, how order is scoped, how a snapshot meets the live log, and how replay converges the sink.

Sources and Further Reading

• Debezium documentation
• Debezium architecture
• Apache Kafka documentation
• PostgreSQL logical replication

Research note: Sources checked 2026-09-06. Platform settings, recruiting schedules, and technical documentation can change; verify the exact invitation or current release before acting.