The source transaction was atomic in the source. The downstream projection is a different system, with different topics, consumers, offsets and visibility rules. Individual event delivery does not make a multi-table materialized view transactionally visible to readers. Debezium's PostgreSQL connector documentation describes transaction metadata, including ordering information, when enabled. That can help a consumer identify boundaries, but it does not automatically commit multiple target indexes as one snapshot.

I would compare source transaction ID and commit position, the two row-change events, topic partitions, consumer offsets and target projection versions. Check whether both events were emitted and merely processed at different times, or whether one was dropped. If they are present, the report needs an explicit consistency contract. It can wait until every required projection has applied at least the source commit position, read a source snapshot, or publish a versioned report only after the transaction's relevant changes have been staged together. A watermark per table is useful only if it represents compatible source positions and the reader knows what a consistent cut means. Taking the numerical minimum of unrelated offsets is not enough.

For a highly used reporting path, I would build a projection that applies the related changes under one target transaction or exposes a committed report version. For an exploratory AI question, the assistant can check the projection lag and decline to assert a cross-table inconsistency while sources are at different positions. The answer should state the source cutoff it used. If the source spans separate databases with no single commit, a transaction ID cannot magically create atomicity across them. Then the business definition must tolerate or reconcile partial state.

The interviewer may ask whether simply waiting five seconds solves it. It reduces ordinary lag and gives no guarantee during a stalled consumer. A bulk snapshot races the change stream concerns the initial snapshot meeting a change stream. The index event arrived, but the document transaction rolled back. What should search believe? concerns an event published before its database transaction commits. Here the database committed correctly and the CDC stream is complete, yet readers observed a partially applied cross-table transaction downstream.