Since the introduction of better clustering support and message queue failover in v2.6, my company is starting to consider moving to RabbitMQ. &nbsp;But we had a few questions about the roadmap.<div><br></div><div>We are looking to ensure that a message is only considered received by an exchange from a producing app when at least two physical instances of Rabbit acknowledge the receipt of the message--similar to Riak's method. &nbsp;Furthermore, we are looking to ensure that a message is considered consumed (ack'd) when when at least one physical instance receives the ack, which may result in a message being delivered more than once. &nbsp;Essentially, we'd like to propose a configuration where Rabbit can fall on the AP side of CAP instead of the CA side.</div><div><br></div><div>I should mention that we're fully aware that the above scenario may cause a message to be pushed to consumers more than once and how messages may get out of order. &nbsp;In general, however, these concepts are very much a part of message queuing system guarantees--that of&nbsp;<b>at-least-once</b>&nbsp;delivery where order is not strictly guaranteed. &nbsp;If we needed <b>at-most-once</b> delivery and strict ordering, we'd use RPC. &nbsp;In many regards, this is similar to the Amazon SQS architecture with a few key differences--one of the most important being stateful connections and "push" capabilities between the server and connected consumers which is where Amazon's SQS offering falls apart--that and message size restrictions.</div><div><br></div><div>I can see that many systems really want to ensure at-most-once delivery (or close to it) and how the requirement to re-order messages makes things difficult, but by relaxing the constraints (at least in some configurations), it enables so much more. &nbsp;For example, if an instance of Rabbit goes offline under the current HA configuration, when it rejoins the cluster the queues are wiped clean. &nbsp;Yuck. &nbsp;So much for guaranteed delivery. &nbsp;While under some kind of partition-tolerant configuration, the queues wouldn't need to be cleaned. &nbsp;Instead, the consuming application would be responsible for message idempotency.</div><div><br></div><div>At the same time, I realize that you guys might be bumping against restrictions in the AMQP standard, for example multiple consumers receiving copies of the message where one consumer ack's the message, while another nack's the message. &nbsp;But that's something where the messaging system can't determine the proper course of action without knowing the business context. &nbsp;In that case, I would imaging it should present that nack back to the producer as it currently does.</div><div><br></div><div>The bottom line in my question and proposal really has to do with message loss. &nbsp;If the idea is to <b>not lose messages</b>, I can see a partition-tolerant configuration bringing a lot to the table and where the consuming application must be resilient to duplicate messages and ordering, thus freeing up RabbitMQ from having to worry so much about that.</div>