Assume every message can arrive more than once and make processing idempotent. Derive a stable key from the message, and either check and record it in a store before acting or use a conditional write so a repeat is a no op. Set the visibility timeout above your worst case processing time, extend it for long jobs, and send messages to a dead letter queue after a few failures so poison messages do not block progress.
Why interviewers ask this
Duplicate delivery is one of those realities that separates people who have run distributed systems from people who have read about them. The interviewer wants idempotency as the first answer, expressed concretely rather than as a word, plus operational details like visibility timeouts and dead letter queues. Handling ordering and partial failure correctly is what turns a working consumer into a reliable one.
How to structure your answer
- Accept duplicates as normal and make idempotency the design center.
- Give a concrete idempotency mechanism, not just the term.
- Cover visibility timeouts and long running work.
- Handle poison messages, retries with backoff, and ordering.
Example answer
I start from the assumption that every message will arrive at least twice at some point, usually because a consumer was slow and the visibility timeout expired while the work was already committed. So the consumer has to be idempotent, and I want that to be concrete rather than aspirational. Usually that is an idempotency key from the message, either an id the producer set or a hash of the meaningful content, recorded in a table with a unique constraint inside the same transaction as the work. If the insert conflicts, we have already done this, acknowledge and move on. Where the effect is a write to a store I prefer a conditional update instead, so applying it twice lands in the same state. Operationally the visibility timeout has to exceed the slowest realistic processing time, and for genuinely long jobs I extend the lease as I go rather than setting a huge global timeout. Failures retry with exponential backoff and jitter, and after a small number of attempts the message goes to a dead letter queue with the error attached, so one bad message never blocks the rest.
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
- How do you handle a side effect you cannot make idempotent, like sending an email?
- How would you reprocess a dead letter queue safely?
- What changes if you also need strict ordering?
Related cloud engineer 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