Pub/Sub: One Event, Many Listeners

A message queue hands each note to exactly one worker, and the whole point is that the work gets done once. This piece is about the opposite need. Sometimes one thing happens and many different services all need to hear about it at once. That is pub/sub.

Imagine a company where, every time an order ships, someone has to personally phone the billing team, then the warehouse, then the email team, then the analytics team. It is slow, and worse, the caller has to know every team that cares and remember to call any new ones. Now replace the phone calls with a single notice pinned to a board. Every team that cares subscribes to the board; the moment a notice goes up, each subscriber gets its own copy and acts on it. The announcer posts once and never has to know who is listening.

That board is publish-subscribe, or pub/sub. A publisher posts an event to a topic, a named channel, and every subscriber to that topic receives its own copy. The publisher and the subscribers never talk to each other directly.

Fan-out: one event, many listeners

The notice reaches every subscribed team the moment it goes up, and the person who posted it does not lift a finger to deliver it. That is the whole idea.

A publisher sends an event to a topic. Every subscriber of that topic gets a copy, at the same time, and the publisher does not know who the subscribers are, how many there are, or what they do. This is called fan-out. The real payoff is not speed, it is extensibility: to make a brand-new service react to "order shipped," you subscribe it to the topic, and you never touch the publisher.

Worked example. "Order shipped" is published once. Four subscribers each get their own copy and act independently: the email service sends a shipping email, the SMS service texts a tracking link, the mobile push service pings the phone, and the in-app service drops a badge in the app. This is exactly how a notification system works, one event fanned out to every channel, and adding a new channel later, say WhatsApp, is just one more subscriber on the topic.

One event, many listenersinteractive

An event happens: an order ships.

Not a queue: a copy for everyone

Here is the one distinction to hold onto, because it is the whole difference from the last piece. Think of a shared to-do list where whoever grabs a task owns it, versus an announcement that everyone in the room hears.

A message queue distributes work: one message is handled by exactly one worker in the pool, so five workers clear a backlog five times faster. A topic broadcasts events: one event is copied to every subscriber, so each does its own separate thing. A queue says "get this done once, by anyone." A topic says "let everyone who cares know." Reach for a queue to spread a single workload across workers; reach for a topic to tell several independent services about the same fact.

Distribute vs broadcastinteractive

The same event arrives at both a work queue and a pub/sub topic.

A queue per subscriber

In practice you rarely wire a topic straight into a service. You put a queue in front of each subscriber, so each subscribed team has its own inbox. The topic drops a copy of the event into every subscriber's own queue, and each subscriber then drains its queue at its own pace, retries its own failures, and dead-letters its own poison messages, all the machinery from the last piece, one copy per subscriber.

The reason to bother is isolation. If the analytics service is slow or down, its queue simply backs up, while email and SMS keep flowing, completely unaffected. A single slow subscriber cannot stall the others, because they are not sharing anything. This is the well-known Amazon SNS to SQS pattern: SNS is the topic that fans out, and each subscriber is its own SQS queue.

A queue per subscriberinteractive

Behind the topic, each subscriber has its own queue.

What actually runs

Three names cover most of it.

Amazon SNS (Simple Notification Service) is topics that fan out to SQS queues, Lambda functions, HTTP endpoints, email, SMS, and mobile push. Paired with SQS, a queue per subscriber, it gives you the durable, isolated pattern above, and this SNS-to-SQS fan-out is the backbone of many real notification systems. Google Cloud Pub/Sub is topics with subscriptions, where each subscription behaves like a per-subscriber queue; it is at-least-once by default, with exactly-once and ordering available as options. Redis pub/sub is the fast, simple version, and the one to handle with care: it is fire-and-forget, at most once, with no persistence, no acknowledgments, and no replay. A message sent while a subscriber is disconnected is gone for good. It is a fine fit for live, throwaway signals, like a "user is typing" indicator, and a poor fit for anything you cannot afford to lose.

The shape to remember: a topic for the fan-out, and a durable queue per subscriber for the isolation and the retries.

Pub/sub delivers each event to today's subscribers, and once a subscriber has consumed its copy, that copy is gone. Which raises a question: what if you want a permanent, replayable record of every event, so a brand-new service added next year could read the whole history from the beginning, and a service that was down for an hour could catch up on exactly what it missed? For that you do not want a queue that empties, you want a log that remembers. That is Kafka, and it is the next piece.

Sources: Fanout to Amazon SQS queues (Amazon SNS); Google Cloud Pub/Sub subscription overview.