First ask what was inside the transaction. Kafka can atomically commit produced Kafka records and the consumed offsets. An external search index is a different state store. Writing there and committing a Kafka offset are two operations unless we have built a separate coordination scheme. Kafka's design documentation says this external-system boundary is the limitation to account for when discussing exactly-once processing.

Suppose the consumer indexes document revision 17 successfully, then crashes before committing offset 900. A replacement consumer reads offset 900 and indexes revision 17 again. If the index write is an upsert with stable document ID, version and deterministic contents, replay may be harmless. If it appends a fresh chunk ID, increments a counter or sends a notification, the duplicate is visible. Reversing the order is worse: commit the offset first, then crash before indexing, and Kafka will not replay that event through normal consumption. Calling the Kafka transaction exactly once does not close either external gap.

For an indexer I would use stable source document and chunk identities, carry a monotonic source revision, and make writes idempotent. A stale revision must not overwrite a newer one. Record progress in the same store as the effect when that store supports an atomic transaction, or use an inbox and durable publication marker with a reconciliation loop that can compare source revision, index revision and Kafka position. Not all search engines offer the same atomicity or external versioning semantics, so I would check the actual API before claiming the fix is guaranteed.

The interviewer may push for a universal exactly-once switch. There is none across an arbitrary external index. Define the user-visible invariant instead: for each source document, the index eventually exposes at most the latest authorized revision, and replays do not multiply chunks. Test crashes immediately before and after the index call, timeouts with unknown outcome, and partition reassignment. Kafka lag is zero. Why is the search index missing yesterday's updates? covers zero Kafka lag with missing index updates. Here the advertised transaction works within Kafka, while the external index effect can be repeated.