zlacker

>>mpweih+(OP)
One important drawback of SQS is that it's eventually consistent, you can read the same message twice from different workers. Nevertheless we keep using it with additional checks when it's critical, it's still the cheapest solution by maintenance.

>>varela+Z9
Making the processing of a message idempotent is the ideal way to handle that limitation

>>lclark+yb
That's not always possible. Thus a big no-no for SQS if that's what you need. Concluding: SQS cannot replace RabbitMQ in all usecases.

>>cies+Ff
If you’re message consumer isn’t idempotent then no MQ can help you. Exactly once delivery is impossible other than with at least once delivery and an idempotent consumer.

https://bravenewgeek.com/tag/amazon-sqs/

>>tybit+gh
> Exactly once delivery is impossible other than with at least once delivery

Can you explain this? Don't many applications deliver once and only once via locking? It's obviously easier as an application developer to say "I will only get this once" and accept losing messages than dealing with idempotence particularly in distributed services.

>>nkozyr+Rn
What if your server dies right as it's about to release that lock and mark the job done? How will you ever know if it was completed or not?