Typically the producer sticks the message onto a single queue that all consumers read from, with locking to ensure only one gets the message.

However, the 3rd scenario works brilliantly if all consumers receive the same message and decide whether they will process it or not. I've used that approach many times with great success, but you must have a way of diffusing which consumer will process the message and of you so not, then all of them will. This may not be such a problem, for example a UI can use such a system and a message will be passed to all consumers (eg UI elements) that pass the criteria (eg they are under the mouse cursor when the event is raised).

So ultimately the answer here is "it depends" on what your messages are and how your consumers process them.

For further reading I'd look at the zeromq guide, they go into some detail about lots of different message queuing systems and the benefits/disadvantages of them.

Typically the producer sticks the message onto a single queue that all consumers read from, with locking to ensure only one gets the message.

However, the 3rd scenario works brilliantly if all consumers receive the same message and decide whether they will process it or not. I've used that approach many times with great success, but you must have a way of differentiating which consumer will process the message and if you cannot, then all of them will. This may not be such a problem, for example a UI can use such a system and a message will be passed to all consumers (eg UI elements) that pass the criteria (eg they are under the mouse cursor when the event is raised)

So ultimately the answer here is "it depends" on what your messages are and how your consumers process them.

For further reading I'd look at the zeromq guide, they go into some detail about lots of different message queuing systems and the benefits/disadvantages of them.