3 ms·
> Guaranteed delivery of a message once That flies in the face of my distributed systems knowledge. It's not possible in some failure cases. If your acknowled
by eloff 6y ago
> Guaranteed delivery of a message once
That flies in the face of my distributed systems knowledge. It's not possible in some failure cases.
If your acknowledgement of a message gets lost (because either server involved or the pipes in-between fail) you've processed the message already but the queue server will think you haven't. It either has to resend it (duplicate delivery) or it ignores acknowledgements all together (drops messages that it sent you, but you didn't process - maybe because your server failed.) So the choice when there is a failure in the system is between at least once or at most once - exactly once cannot be guaranteed.
I'm not aware of any way around that predicament.
- whatsmyusername 6y agoYou are correct, a better description is that their path to 'deliver exactly once to the best of your ability' is clearer. If I remember correctly SQS is hard limited to a fairly short timeout to requeue messages delivered but not acked. In rabbit it's much more configurable. Also regular rabbit hosts support the kludge pattern of, 'just run one host and accept if it goes poof you can lose messages,' which is useful if you don't want to bother with the complexity of clustering or are on a shoe string budget. Lastly you get a nice user interface with the management plugin and you can stand it up locally with docker compose (without depending on AWS for dev or any of the 'aws but on your laptop' solutions).
- eloff 6y agoYeah, those are nice features to have. Plus you don't get the platform lock in.
- whatsmyusername 6y agoNormally I don't give a crap about vendor lock-in, but this would be an exception where I'd agree with you. Though most people are just going to use a framework plugin to manage the messaging layer, so what's behind that is largely irrelevant.