Message Queue vs PubSub

TL;DR

	Message Queue	PubSub
Consumers	one and only one consumer	allows multiple consumers
Message Deletion	after ONE consumer ack consumption	after ALL consumers ack consumption
Message Process Order	may be out of order if multiple consumers	messages are received in order by each consumer

A single queue, events may be distributed to multiple consumers.

Each message for a given topic or channel is delivered to and processed by exactly one consumer. (e.g. every paycheck is issued once and only once)
Supports high rates of consumption by adding multiple consumers for each topic, but only one consumer will receive each message on the topic.
The message will be deleted once a consumer has acknowledged consumption of the message.
In the case of network or consumer failures, the message queue will try resending an affected message at a later time (not necessarily to the same consumer) and as a result, that message may be processed out of order.

One topic may have mutilple consumers (subscribers). One queue per each consumer (subscriber).

decoupling publishers and subscribers:
- Publishers need not target their messages to specific subscribers nor even know how many subscribers there will be.
- Publishers and subscribers need not even be running at the same time
- Publishers and subscribers can be implemented in different languages / frameworks.
message persistence: messages are kept in permanent storage until they have been acknowledged by all interested subscribers. Persistence allows client applications to be resilient in the face of intermittent application, network, and machine failures.

Use message queues if a consumer application instance goes down then another consumer will be able to handle the message instead.
Use pubsub, if a subscriber is down then once it has recovered the messages it has missed will be available for consumption in its subscribing queue.

Message Queues:

Distributed PubSub:

Cloud:

By Martin KleppmannView on Amazon

Versus