Skip to main content

Pub/Sub

Publish/subscribe (pub/sub) is a messaging pattern where a publisher sends a message to a named topic, without knowing or caring who — if anyone — is listening, and any number of subscribers independently receive their own copy of every message published to a topic they've subscribed to. The publisher and subscribers never talk to each other directly; a topic sits between them as the only thing either side needs to know about.

Decoupling, taken further than a direct call​

Every synchronous request/response covered in the API Fundamentals module — a client calling an API, one service calling another directly — creates a dependency: the caller has to know the callee's address, and both have to be up at the same time for the call to succeed. Pub/sub removes both requirements. A publisher doesn't address any specific subscriber, doesn't know how many there are, and doesn't need them to be running at the exact moment it publishes — it just emits an event to a topic and moves on. This is a stronger form of decoupling than Webhooks already introduced: a webhook is still a direct, one-to-one HTTP call from one service to a URL it was explicitly configured to know about, while pub/sub can fan the same event out to an open-ended, changing set of subscribers with no per-subscriber configuration on the publisher's side at all.

System Design Lab

Fan-out is the whole point​

The defining property of pub/sub is that every subscriber to a topic gets every message published to it — this is fan-out, and it's fundamentally different from how a Load Balancer distributes work. A load balancer spreads different requests across interchangeable replicas of the same service, so any one request goes to exactly one replica. Pub/sub instead sends the same event to potentially many different services, each of which does something entirely different with it — an "order created" event might trigger an email, a warehouse pick, and an analytics update simultaneously, each handled by a completely different subscriber that knows nothing about the others.

This is what makes pub/sub the natural fit for event-driven architectures: a service that changes state doesn't need to know who cares — it just publishes what happened, and any current or future subscriber can react without the publisher ever being modified to know about them.

What pub/sub doesn't give you​

It's worth being precise about what pub/sub does and doesn't guarantee, since it's easy to conflate with a Message Queue:

  • No built-in work distribution. If three instances of the same subscriber service all subscribe to a topic to share load, plain pub/sub delivers the message to all three, not to just one of them — fan-out is per-subscriber-group, not a way to load-balance identical workers. Systems that need "many workers, each message handled once" reach for a message queue instead, or a pub/sub system with an explicit consumer-group concept layered on top (like Kafka's).
  • Delivery isn't always durable by default. A simple pub/sub system can drop a message if no subscriber is currently connected to receive it — durable pub/sub systems address this by persisting messages so a subscriber that reconnects later can catch up, but that's a deliberate design choice, not a property of the pattern itself.

Why this matters in an interview​

Pub/sub is the right answer specifically when one event needs to trigger multiple, independent, unrelated reactions across different services — naming it (and specifically naming fan-out as the property being used) is stronger than a vague "the services will communicate asynchronously." It's also worth being ready to draw the line against a message queue: if the real need is "distribute this work across a pool of identical workers," that's a queue's job, not pub/sub's.

Pub/sub vs. direct service-to-service calls: pros and cons​

Pros

  • Publisher never needs to know who — or how many — subscribers exist
  • New subscribers can be added later with zero changes to the publisher
  • One event can trigger many independent reactions without a growing web of direct calls

Cons

  • Harder to trace a single event's full effect across a system than following a direct call
  • Delivery and ordering guarantees vary by implementation and must be chosen deliberately
  • Debugging "who is supposed to react to this" requires knowing the topic's subscribers, not just reading code

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.