How Pub/Sub Works
BeginnerPublish-subscribe (pub/sub) is a messaging pattern where senders (publishers) do not send messages to specific receivers. Instead they publish to a topic, and every subscriber to that topic receives a copy. Publishers and subscribers never know about each other — they are decoupled through the topic. This fan-out delivery makes pub/sub ideal for broadcasting events to many independent consumers, the backbone of event-driven architectures.
Think of a radio broadcast
A radio station (publisher) broadcasts on a frequency (topic) without knowing who is listening. Anyone who tunes to that frequency (subscribers) hears the broadcast; each gets their own copy of the audio. The station does not address individual listeners, and listeners can join or leave anytime. That decoupling — broadcast to a channel, not to named recipients — is exactly pub/sub.
Step by Step
Key Concepts
Topic
A named channel publishers send to and subscribers listen on. It is the decoupling point — publishers and subscribers only know the topic, never each other.
Fan-out Delivery
Every subscriber to a topic receives its own copy of each message. This one-to-many broadcast distinguishes pub/sub from a queue, where each message goes to a single consumer.
Pub/Sub vs Message Queue
A queue delivers each message to exactly one consumer (competing consumers). Pub/sub delivers each message to all subscribers. Many systems combine both — e.g., Kafka consumer groups give queue-like behaviour on top of pub/sub topics.
Decoupling
Publishers and subscribers are independent — they can be added, removed, or scaled without changing each other, which makes event-driven systems flexible and extensible.
Key Facts
- The defining feature is one-to-many fan-out: unlike a queue, every subscriber gets its own copy of each message.
- Pub/sub enables extensibility — adding a new consumer of events requires no change to the producers.
- Kafka blurs the line: its topics are pub/sub, but consumer groups let a set of consumers share partitions like a queue, giving both behaviours.
Real-World Applications
Broadcasting domain events
An order-placed event is published once; email, inventory, analytics, and recommendation services each subscribe and react independently, and new consumers can be added without touching the publisher.
Real-time updates to many clients
A chat or live-scores system publishes updates to a topic; every connected client subscribed to that topic receives the update simultaneously via fan-out.
Frequently Asked Questions
What is the publish-subscribe pattern?
It is a messaging pattern where publishers send messages to a named topic rather than to specific receivers, and all subscribers to that topic receive a copy. Publishers and subscribers are fully decoupled — they only know the topic, not each other. This enables one-to-many broadcast of events and makes systems easy to extend with new consumers.
What is the difference between pub/sub and a message queue?
In a message queue, each message is delivered to exactly one consumer among competing consumers — it is one-to-one work distribution. In pub/sub, each message is delivered to every subscriber of the topic — it is one-to-many broadcast. Queues are for distributing work; pub/sub is for broadcasting events to multiple independent consumers.
Why is pub/sub good for event-driven architecture?
Because publishers and subscribers are decoupled, one published event can trigger many independent reactions, and you can add new subscribers (new features or consumers) without modifying the publisher. This loose coupling and easy extensibility is exactly what event-driven systems need to evolve safely as requirements grow.
What are some pub/sub implementations?
Common ones include Apache Kafka (topics with consumer groups), Google Cloud Pub/Sub, Amazon SNS, Redis Pub/Sub, and NATS. They differ in durability, ordering, delivery guarantees, and scale — for example, Kafka retains messages for replay, while Redis Pub/Sub is fire-and-forget — so you choose based on whether you need persistence, ordering, and replay.