The answer is rather simplistic and does not even scratch the surface of the drama surrounding zeromq/nanomsg. I knew a big part of the reliability problems we

The answer is rather simplistic and does not even scratch the surface of the drama surrounding zeromq/nanomsg. I knew a big part of the reliability problems we were having was related to the distributed state that needed to be kept synchronized. I wanted to move to something simpler that did not rely on any durable, distributed state, while supporting the messaging patters we required. ZeroMQ fit the bill. While there were other implementations with similar properties, there is no reasonable way to compare them up front given that what makes the real difference at the end of the day is the behavior of the system at 2am one day after a prolonged stress run. As a startup one does not have resources to conduct an up front analysis of that sort. You just take a bet. If it does not pan out, you pivot. This is exactly what we have done with the move from Kafka to ZeroMQ in the first place. Now that we've been using ZeroMQ for over a year and have been perfectly happy, there is no incentive to look elsewhere.