I would definitely call it a design flaw. After all, RabbitMQ pretends to be multi-master; but if you set up clients to treat a single node (of several) as a ma

I would definitely call it a design flaw. After all, RabbitMQ pretends to be multi-master; but if you set up clients to treat a single node (of several) as a master, the other nodes will be reduced to being dumb backup nodes. Also, don't forget that clients don't decide which node owns a queue — it's owned by the node where it's first created. Being consistent about always talking to the correct node, and keeping track of which node owns the master replica of any given queue, puts a complicating burden on both clients and the system administrator. You can run RabbitMQ without any partition handling, but that means the ops staff needs to wake up in the middle of the night to handle downtime. Not to mention that there's no queue merging support — at the very least, it could be possible to merge conflicting queues where you don't particularly care about ordering.