Publish/subscribe pattern: Messages to many recipients

In short: A sender publishes messages on a topic without knowing the recipients; everyone who has subscribed to the topic receives them.

In more detail: With publish/subscribe (pub/sub), sender (publisher) and receiver (subscriber) are decoupled. In between sits an intermediary, the broker. The publisher does not know who is listening, the subscribers do not know who is sending. This makes systems easy to extend: a new recipient simply subscribes to an existing topic.

In Depth

Building blocks

• Topic (subject, channel): the name under which messages are published, e.g. order.new.
• Publisher: sends messages to a topic.
• Subscriber: subscribes to topics and processes incoming messages.
• Broker: accepts messages, distributes them and can buffer them. Examples: MQTT brokers, Redis pub/sub, Google Pub/Sub, Apache Kafka.

Difference from a queue

In a classic queue each message goes to exactly one of several competing consumers. With pub/sub every subscriber receives a copy. Many systems combine both: several services subscribe to a topic, and within one service several instances share the work (consumer groups).

Example in JavaScript with Redis

// receiver
subscriber.subscribe('order.new', (msg) => console.log('New:', msg));
// sender
publisher.publish('order.new', JSON.stringify({ id: 42 }));

The invoicing service and the shipping service can subscribe to the same topic and react independently of each other.

Things to watch

Plain Redis pub/sub stores nothing: whoever is not connected at the moment misses the message. For reliable delivery you need brokers with storage and acknowledgements. Because the same message can arrive more than once, receivers should work idempotently. Depending on the system, ordering is guaranteed only per partition or not at all.

See also: Message queue, Apache Kafka, Observer pattern, Webhooks