> Well, in Akka you can use journaling and persistence to prevent important messages from being lost in case of error. That is not a problem. [1] No it is more

> Well, in Akka you can use journaling and persistence to prevent important messages from being lost in case of error. That is not a problem. [1] No it is more complicated than just one step guaranteeing. Lots of things do that including Apache Flume and just about any log aggregator. Because RabbitMQ is a broker, has exchanges and transactions it guarantees multiple steps as well as properly load balances. For example lets say you have a consumer that gets a critical message and that machine (node, vm, docker whatever) gets completely blown away along with its storage than the message is lost. With RabbitMQ the broker is the single point of failure. Of course this comes at a cost (complexity and partitioning problems). I believe Akka has a server model but from what I heard it is not very battle tested. The other thing is Akka just like ZeroMQ and just like any other message platform can basically emulate (or imitate) almost any other message style/platform as well as chain them together (your point of akka + camel). The question is how robust and battle tested is the solution for the particular problem domain? Do you want smart pipes and dumb consumers (rabbit) or dumb pipes and smart consumers (akka, zeromq, rest).