Publish/Subscribe (Pub/Sub)

What is it?

A queue is great when exactly one worker should handle each piece of work. But sometimes an event needs to be delivered to every interested party, not just one — a new order might need to trigger an email, an inventory update, and an analytics event, all at once. Publish/Subscribe (pub/sub) solves this: a publisher sends a message to a named topic, and every subscriber currently listening to that topic receives its own copy.

Explain like I'm 10

It's like a radio broadcast. The radio station (publisher) doesn't know or care who's listening — it just broadcasts on its frequency (the topic). Anyone with a radio tuned to that frequency (a subscriber) hears the exact same broadcast, independently of everyone else.

Examples

One event, multiple independent subscribers

// Publisher
eventBus.publish("order.created", { orderId: 42 });

// Subscriber 1
eventBus.subscribe("order.created", (event) => {
  sendConfirmationEmail(event.orderId);
});

// Subscriber 2 — completely independent of subscriber 1
eventBus.subscribe("order.created", (event) => {
  updateAnalytics(event.orderId);
});

How it works

A pub/sub system maintains a set of topics, each with zero or more subscribers. When a publisher sends a message to a topic, the system delivers a copy of that message to every current subscriber of that topic, independently — publishers and subscribers never talk to each other directly, and neither needs to know the other exists.

Why does it exist?

Pub/sub lets you add a brand-new reaction to an existing event (like a new notification type, or a new analytics hook) without touching the code that publishes the event at all — the publisher and every subscriber can be developed, deployed, and scaled completely independently of each other.

When to use it

Reach for pub/sub whenever one event genuinely needs to trigger multiple independent reactions, especially across different services or teams, and especially when new subscribers might be added later without changing the publisher.

When not to use it

If exactly one worker should handle each message (like processing a payment exactly once), a queue is the right tool, not pub/sub, which is designed for broadcasting to many listeners rather than distributing work to exactly one.

Common mistakes

• Confusing pub/sub (every subscriber gets every message) with a queue (exactly one worker gets each message) — they solve different problems.

• Assuming a subscriber that's offline when a message is published will still receive it later — depending on the system, that message may simply be missed unless durability/replay is explicitly configured.

• Publishing overly specific, tightly-coupled event data that assumes exactly which subscribers exist, defeating the purpose of the publisher not needing to know who's listening.

Practice exercises

1. Easy:

   Explain, in your own words, the difference between a queue and pub/sub.

2. Medium:

   Describe a real feature (e.g. a new order) and list three independent subscribers that might react to it via pub/sub.

3. Hard:

   Explain what could go wrong if a subscriber is temporarily down when an important event is published, and how a system might guard against losing that event.

Interview questions

What is publish/subscribe (pub/sub)?

A messaging pattern where a publisher sends messages to a named topic, and every current subscriber of that topic receives an independent copy, without publisher and subscriber knowing about each other.

What's the key difference between pub/sub and a message queue?

A queue delivers each message to exactly one consumer; pub/sub delivers each message to every subscriber of that topic.

Why is pub/sub useful for adding new features?

A new subscriber can be added to react to an existing event without any change to the code that publishes it.