Publish/Subscribe: One Event, Many Independent Readers

Publish/subscribe, often shortened to pub/sub, delivers each message to every reader that has subscribed. A publisher sends a message to a topic, a named channel, and the topic gives a copy to each subscriber. The publisher does not know who the subscribers are, so new ones can be added without changing it.

What a message is here. Usually an event: a statement that something happened, such as "price of item 812 changed to 19.99". The publisher announces it and moves on. Each subscriber decides for itself what to do with it.

How it differs from a queue. On a queue, three workers share the messages: each message is handled once. On a topic, three subscribers each receive every message: each message is handled three times, once by each, for three different purposes.

Topics and queues together. A common arrangement gives each subscribing service its own queue, subscribed to the topic. The topic copies each event into every queue, and within each service, several workers share that service's queue. Amazon Simple Notification Service (SNS) topics feeding SQS queues is a widely used form.

What it costs. The publisher cannot know whether anyone acted on its event, or when. A subscriber that falls behind or fails does not slow the publisher, but its copy must wait somewhere, which is why a queue per subscriber is common.

Products. Amazon SNS and Google Cloud Pub/Sub are publish/subscribe services. Apache Kafka, a log of events that many readers can each read at their own pace, is often used the same way.

So use publish/subscribe when several independent services must each react to the same event, and let each subscriber own what it does with it.