Messages are indeed idempotent. As I mentioned, if the response is lost you resend, until you do get a response. The server will accept the same message over an

Messages are indeed idempotent. As I mentioned, if the response is lost you resend, until you do get a response. The server will accept the same message over and over, until the client stops sending the message (i.e. the server response was received by the client). The server simply discards any subsequent messages. That message integrity is verified with a hash value goes without saying. The two generals problem is a non-problem. Messages don't equate to messenger's lives, in that there is no cost equivalent to a loss of life when resending a message. Also, the probability of not receiving a server response after n attempts is virtually null. Ref. how the internet continues to work. Atomicity is only relevant where there's a batch. Delivery of all messages in a batch is taken care of as described in the previous paragraph, and I'm therefore satisfied that transmission will work. Persistence on the client and server is therefore where atomicity applies, and is subject to the same constraints that any database transaction is subject to (again, the risk impact is high, but the probability so low that while I could, I don't even bother[1]). I don't see a problem here. [1] Hardware is quite sufficiently reliable these days. If I ever had to work in a scenario in which the cost of loss is sufficiently high (even considering the low probability of loss), then I'm still not sure what you suggest I do, because messages aren't placed onto a queue as a single operation. They're discreet. If they weren't I'd bundle them as a single message, and so wouldn't face the problem in the first place.