Your consumer must tolerate duplicate Kafka messages. What is the practical pattern?
PICTURE THIS: DATA SPLIT
Fit on train, tune on val, report on test once.
Simple meaning
Store a unique event id or (topic, partition, offset) in a processed table with a unique constraint, and ignore duplicates.
WHY — Kafka instead of guessing?
Why interviewers care about Kafka:
who only read docs from people who shipped.
and tied to Backend work.
Name the idea, why it exists, then one short example.
End with when you use it and one common pitfall.
STEPS — What happens step by step?
Before you speak the answer, walk the interviewer through these steps:
- 1Store a unique event
id or (topic, partition, offset) in a processed table with a unique constraint, and ignore duplicates.
- 2Make the side effect
itself idempotent, like UPSERT.
- 3Do not rely on
Kafka exactly-once if you write to a system that is outside the Kafka transaction.
- 4Give an example
One tiny concrete case you can say aloud.
- 5Common mistake
What juniors usually get wrong.
- 6Close
When you pick this over the alternative.
EXAMPLE — See it in action
Here's a short line you can speak, broken into clear beats:
Note: Adapt this scaffold to your own project — keep it under 60–90 seconds.
Key takeaway
Store a unique event id or (topic, partition, offset) in a processed table with a unique constraint, and ignore duplicates. Make the side effect itself idempotent, like UPSERT.