Messaging Confusion: Pub/Sub vs Multicast vs Fan Out

Question

I've been evaluating messaging technologies for my company but I've become very confused by the conceptual differences between a few terms:

Pub/Sub vs Multicast vs Fan Out I am working with the following definitions:

• Pub/Sub has publishers delivering a separate copy of each message to each subscriber which means that the opportunity to guarantee delivery exists
• Fan Out has a single queue pushing to all listening clients.
• Multicast just spams out data and if someone is listening then fine, if not, it doesn't matter. No possibility to guarantee a client definitely gets a message.

Are these definitions right? Or is Pub/Sub the pattern and multicast, direct, fanout etc. ways to acheive the pattern?

I'm trying to work the out-of-the-box RabbitMQ definitions into our architecture but I'm just going around in circles at the moment trying to write the specs for our app.

Please could someone advise me whether I am right?

Answer 1

I'm confused by your choice of three terms to compare. Within RabbitMQ, Fanout and Direct are exchange types. Pub-Sub is a generic messaging pattern but not an exchange type. And you didn't even mention the 3rd and most important Exchange type, namely Topic. In fact, you can implement Fanout behavior on a Topic exchange just by declaring multiple queues with the same binding key. And you can define Direct behavior on a Topic exchange by declaring a Queue with * as the wildcard binding key.

Pub-Sub is generally understood as a pattern in which an application publishes messages which are consumed by several subscribers.

With RabbitMQ/AMQP it is important to remember that messages are always published to exchanges. Then exchanges route to queues. And queues deliver messages to subscribers. The behavior of the exchange is important. In Topic exchanges, the routing key from the publisher is matched up to the binding key from the subscriber in order to make the routing decision. Binding keys can have wildcard patterns which further influences the routing decision. More complicated routing can be done based on the content of message headers using a headers exchange type

RabbitMQ doesn't guarantee delivery of messages but you can get guaranteed delivery by choosing the right options(delivery mode = 2 for persistent msgs), and declaring exchanges and queues in advance of running your application so that messages are not discarded.