It means duplicates are normal, not exceptional, so your consumer has to be idempotent. Derive a stable key from the message, record processed keys in the same transaction as the effect, and treat a repeat as a no op. Also expect out of order delivery and redelivery after a crash between doing the work and acknowledging. Exactly once end to end does not exist across systems; you get at least once plus idempotent handling.
Why interviewers ask this
This is the single most common source of duplicate charges and duplicate emails in event driven systems. The interviewer wants to know whether you design consumers defensively or assume the broker will protect you. Mentioning the acknowledgment window, a dedupe table written in the same transaction, and a dead letter queue shows you have operated a consumer rather than only written one.
How to structure your answer
- State plainly that duplicates will happen and why.
- Give the idempotency mechanism, including where the record is written.
- Cover ordering and the acknowledgment window.
- Add failure handling: retries with backoff and a dead letter queue.
Example answer
It means I will get the same message twice, usually because the consumer did the work and then died before acknowledging, so the broker redelivers. So the consumer has to be safe to run twice with the same input. In practice I take a stable id from the message, and when I write the effect I write the processed id in the same database transaction, with a unique constraint. If the insert conflicts I know I have already handled it and I acknowledge without redoing the work. The critical part is that the dedupe record and the effect commit together; if I write them separately there is a window where I can duplicate. I also assume ordering is not guaranteed, so handlers are written to tolerate an update arriving before the create, usually by keying on the entity and checking a version. For failures I use a bounded retry with exponential backoff and jitter, then a dead letter queue with an alert, because silently retrying a poison message forever is how a queue backs up overnight.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- Where exactly would you store the deduplication key, and for how long?
- How do you preserve ordering when you need it?
- What is your process for draining a dead letter queue?
Related backend developer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions