What is the Publish-Subscribe (Pub/Sub) Pattern?
Learn the publish-subscribe (pub/sub) messaging pattern: topics, fan-out delivery, decoupling, and event-driven architecture use cases.
Expected Interview Answer
The publish-subscribe (pub/sub) pattern is a messaging model where publishers send messages to a topic without knowing who receives them, and subscribers register interest in that topic to receive messages asynchronously, decoupling producers and consumers in time, space, and scale.
A publisher writes a message to a named topic or channel on a broker (such as Kafka, Redis Pub/Sub, or SNS), and the broker fans that message out to every subscriber currently listening on that topic. Publishers never address subscribers directly and do not need to know how many exist, how fast they process messages, or whether they are even online, which is what makes the pattern loosely coupled. This differs from a point-to-point queue, where each message is consumed by exactly one consumer; in pub/sub, every subscriber typically gets its own copy of each message. Pub/sub enables event-driven architectures: services react to events (an order placed, a user signed up) by subscribing to relevant topics instead of being directly called, so new subscribers can be added without changing the publisher at all. Trade-offs include eventual consistency between publish and delivery, the need to handle duplicate or out-of-order messages, and the operational complexity of running and monitoring the broker itself.
- Decouples producers from consumers, so each can scale and deploy independently
- Supports fan-out to many subscribers from a single published message
- Enables event-driven architectures that are easy to extend with new subscribers
- Improves resilience since a slow or down subscriber does not block the publisher
AI Mentor Explanation
The pub/sub pattern is like a stadium announcer broadcasting the fall of a wicket over the PA system without knowing exactly who is listening. Every fan tuned in, whether in the stands or listening on radio, hears the announcement independently, and the announcer never has to address anyone by name. New fans can start listening at any time without the announcer changing anything. That broadcast-to-anyone-listening model is exactly the pub/sub pattern.
Step-by-Step Explanation
Step 1
Publisher sends a message
A producer writes an event to a named topic on the broker without addressing any specific consumer.
Step 2
Broker fans out
The broker delivers a copy of the message to every subscriber currently registered on that topic.
Step 3
Subscribers process independently
Each subscriber consumes and reacts to the message on its own schedule, unaware of other subscribers.
Step 4
New subscribers join freely
Additional consumers can subscribe to the topic at any time without any change to the publisher.
What Interviewer Expects
- Clear definition: publishers and subscribers decoupled via a topic/broker
- Distinction from point-to-point queues (fan-out to many vs one consumer per message)
- Named real systems: Kafka, Redis Pub/Sub, SNS/SQS, RabbitMQ topics
- Awareness of trade-offs: eventual consistency, duplicate/out-of-order delivery, broker operational overhead
Common Mistakes
- Conflating pub/sub with a simple point-to-point message queue
- Assuming publishers know or care how many subscribers exist
- Ignoring message delivery guarantees (at-least-once vs exactly-once) trade-offs
- Not mentioning that pub/sub decouples services in time as well as space
Best Answer (HR Friendly)
“Pub/sub is a messaging pattern where a service publishes an event to a topic without knowing who is listening, and any number of other services can subscribe to that topic to get notified. It is useful because it decouples systems from each other, so you can add new features that react to an event without changing the code that originally published it.”
Code Example
// Publisher: fires an event, does not know or care who is subscribed
async function publishOrderPlaced(broker, order) {
await broker.publish("orders.placed", JSON.stringify(order));
}
// Subscriber A: sends a confirmation email
broker.subscribe("orders.placed", async (message) => {
const order = JSON.parse(message);
await emailService.sendOrderConfirmation(order);
});
// Subscriber B: updates inventory, added later with zero publisher changes
broker.subscribe("orders.placed", async (message) => {
const order = JSON.parse(message);
await inventoryService.reserveStock(order.items);
});Follow-up Questions
- How does pub/sub differ from a point-to-point message queue?
- How would you handle duplicate message delivery in a subscriber?
- What happens to messages published while a subscriber is offline?
- When would you choose Kafka over Redis Pub/Sub for a pub/sub system?
MCQ Practice
1. In the pub/sub pattern, how many subscribers typically receive a copy of a published message?
Pub/sub fans a message out to every subscriber on the topic, unlike a point-to-point queue where only one consumer gets each message.
2. What is the key benefit of the pub/sub pattern for system architecture?
Publishers do not need to know who or how many subscribers exist, which lets services be added, removed, or scaled independently.
3. How does pub/sub differ from a point-to-point queue?
In pub/sub, all subscribers on a topic receive a copy of each message, whereas a point-to-point queue distributes each message to only one consumer.
Flash Cards
What is the pub/sub pattern? — Publishers send messages to a topic; any number of subscribers on that topic receive a copy independently.
Pub/sub vs point-to-point queue? — Pub/sub fans out to every subscriber; a queue delivers each message to exactly one consumer.
Why does pub/sub decouple services? — Publishers never address subscribers directly, so subscribers can be added or removed without changing the publisher.
Named pub/sub systems? — Kafka, Redis Pub/Sub, AWS SNS, and RabbitMQ topic exchanges.