Pub/Sub Pattern

Before the internet, how did you get news? You subscribed to a newspaper. The publisher printed one edition and delivered it to thousands of subscribers. The publisher didn't care how many subscribers there were or what they did with the paper. The subscribers didn't care how the paper was printed. They just received it.

This model, one producer broadcasting to many consumers, is called Publish/Subscribe, or pub/sub. And it's the foundation of virtually every event-driven system built in the last two decades.

Here's why it matters: in a message queue, each message goes to exactly one consumer. That's fine for task distribution. But what happens when multiple services need to react to the same event?

A user places an order on an e-commerce platform. Who needs to know?

• The inventory service (to decrement stock)
• The payment service (to charge the card)
• The email service (to send a confirmation)
• The analytics service (to track the conversion)
• The recommendation service (to update the user's profile)
• The fraud detection service (to check for suspicious activity)

With a simple message queue, you'd need to send the same message six times to six different queues. With pub/sub, you publish the "order placed" event once, and every interested service receives a copy. The publisher doesn't know, or care, how many subscribers exist.

This is the pattern that lets Netflix, Google, Uber, and LinkedIn scale to billions of events per day.

Pub/sub introduces a new concept between producers and consumers: the topic (also called a channel or subject).

• Publisher: sends messages to a topic (not to a specific consumer)
• Topic: a named category of messages (e.g., "order-events", "user-signups")
• Subscriber: registers interest in a topic and receives all messages published to it

Every subscriber gets its own copy of every message. Unlike a queue (where each message is consumed by one worker), a pub/sub topic delivers every message to every subscriber.

The critical distinction:

Many systems combine both: a topic fans out events to multiple subscriber groups, and within each group, a queue distributes work among competing consumers. Kafka does exactly this with consumer groups.