Guaranteed messaging is something that I’ve covered before from a Comet perspective. It is still mentioned a lot when talking about messaging technology. People using the technology want to know that if they send a message that it will be received at the other end. The problem is they want this for free.
Many messaging APIs provide various levels of message guarantee which can give a user of the API some comfort in thinking their messages are safe, but are they? Often this is just a box ticking exercise and the word guaranteed is falsely satisfying the users requirement.
If you are writing a system that needs to send messages, then a simple API (to send the message) is unlikely to truly guarantee that it is sent successfully. You need to think about the different scenarios of failure and whether they are all catered for. The chances are there are holes.
An API should only let the user know the message is guaranteed once the message is persisted in a place that it can be resent from – or once the message has actually been consumed by the final recipient. Until the point the API has taken responsibility for the message, your code is responsible for that message and you need to make sure you can guarantee that a failure can be handled appropriately.
Always make sure all failure scenarios are covered, using a messaging system that guarantees messages is no assurance that your whole solution is guaranteed. Take the time to think about it.