How do you make sure a repeated message doesn't cause the effect twice?
Answer out loud or in your head first, then compare.
Answer
I define an identifier for the same operation and record that it has been performed. If I keep the effect and the record of it in one database, they should be saved together in a transaction. A uniqueness constraint in the database helps when two programs try to handle the same event at once.
A plain set of IDs in one server's memory isn't enough after a restart or with many servers. An external payment is harder: a local transaction doesn't cover someone else's API. You need its own protection against repeats, or a check whether the operation already exists. The same identifier with different content should be treated as a conflict.
Why it matters: A practical extension of idempotency, important for agents that perform actions.
Possible follow-ups: What happens after a crash between saving the result and acknowledging the queue?
How did it go? Be honest — “Not yet” puts the question on your review list.
Start with
- D-P10 · What is a database transaction? — Backend, data and system design
- D-P14 · Why can a message from a queue arrive a second time? — Backend, data and system design
- D-P15 · What is idempotency? — Backend, data and system design
Practise in code
- Find the bugs in a queue consumer — guided self-review
Further reading
- AWS: Using Lambda with Amazon SQS(opens in a new tab)Docs; accessed 22.10.2026. Polling, batches, duplicates and partial batch responses.
- PostgreSQL: Transaction Isolation(opens in a new tab)Docs; accessed 22.10.2026. Isolation, locks and serialization anomalies; a good basis for working with an ORM.