What they're testing
Whether you know why exactly-once is impossible in DELIVERY, and how you reach it in PROCESSING instead.
The short answer~30 seconds
At-most-once: fire and forget, may lose. At-least-once: resend until acknowledged, may duplicate. Exactly-once delivery is impossible — the sender can never distinguish "they didn't receive it" from "they received it and the acknowledgement was lost". What's achievable is exactly-once PROCESSING: at-least-once plus an idempotent consumer, or plus writing the result and committing the offset in one transaction.
The long answer
How Kafka does exactly-once is worth understanding because it exposes the real conditions. An idempotent producer numbers records so the broker drops retry duplicates. Then a transaction lets you write to the output topic AND commit the input offset atomically — so if the consumer dies, both roll back together. But that holds only WITHIN Kafka: the moment the result leaves, say into another database, the guarantee is gone.
So in practice the answer is nearly always at-least-once plus an idempotent consumer. How you make it idempotent depends: record processed message ids in a table with a UNIQUE constraint, upsert on a natural key, or design the operation so repetition doesn't change state (SET status = 'paid' is repeatable; balance = balance - 10 isn't).
At senior level, add poison messages: a record that always crashes the consumer gets retried forever and blocks everything behind it in the partition. You need a dead-letter queue with an attempt threshold, and just as importantly a process for what lands there — an unwatched DLQ is a way of silently losing data, just more slowly.
What they'll ask next
?Is message ordering guaranteed?
In Kafka, only WITHIN a partition. To have one entity's events arrive in order you must use the entity id as the partition key. That's an important constraint when choosing it: the key decides both ordering and load balance.
?Commit the offset before or after processing?
After, if you want at-least-once (a disconnect means reprocessing). Before, if you accept loss for at-most-once. enable.auto.commit=true commits on a timer, landing in between with the least reasonable-about guarantee — which is why most serious systems turn it off.
These lose points
- Promising exactly-once without conditions. A senior interviewer will immediately ask "even writing to an external database?"
- No plan for poison messages. They will happen, and they block the whole partition.