Card 06/ 09
Message Queue vs Publish/Subscribe
Share the work, or share the news.
A message queue and a publish/subscribe topic both let a producer hand off a message without waiting, and they differ in one thing: how many readers receive each message. On a queue, one. On a topic, every subscriber. Whether the readers are sharing a job or each reacting for their own purpose decides which you need.
| Axis | Message queue | Publish/subscribe |
|---|---|---|
| Readers per message | One, whichever is free | Every subscriber |
| What a message is | A job to be done | News that something happened |
| Adding a reader | Shares the work, so the same jobs finish faster | Adds a new reaction, and the publisher is unchanged |
| Typical products | Amazon SQS, RabbitMQ | Amazon SNS, Google Cloud Pub/Sub |
Use it when
- The same job must be done once, by any one of several workers
- Bursts of work should wait in line for workers at a steady pace
Avoid it when
- Several different services each need the message
Use it when
- Several services each react to the same event in their own way
- New readers should be added without changing the publisher
Avoid it when
- The message is a job that must be done once; every subscriber would do it
The mistake to expect. Putting thumbnail jobs on a topic with four resizing workers subscribed. Each worker receives every message, so every image is resized four times. Workers sharing a job belong on one queue.
The other way round. Putting a price change on a queue read by search, the cache and analytics. Each message reaches only one of them, so two of the three never hear about the change. Different readers that each need the news belong on a topic.
So ask who must receive each message: one worker sharing a job means a queue, every interested service means a topic.
← → move through sections and cards