What Pub-Sub Is, and How It Differs From a Queue

Why this matters: pub-sub and messaging queues look nearly identical on a whiteboard. One sentence separates them, and getting that sentence right is what makes every later design decision follow.

Key takeaway

Publish-subscribe (pub-sub) messaging is an asynchronous communication method popular in serverless and microservices architectures. It sends messages to multiple subsystems simultaneously — services subscribed to a specific topic receive any message pushed to that topic.

The shape

The canonical example: when a user posts on a social media platform, the platform delivers that post to their followers. The user is the publisher, the post is the message, and the followers are the subscribers.

The one difference from a queue

"What are the similarities and differences between a pub-sub system and queues?"

They are similar because they deliver information from producers to consumers. The difference is that only one consumer processes a message in a queue, whereas multiple consumers can process the same message in a pub-sub system.

	Messaging queue	Pub-sub
Who processes a message	Exactly one consumer	Every subscriber
Adding a consumer	Splits the work — throughput goes up	Duplicates the work — each gets its own copy
Message lifetime	Typically ends when consumed	Governed by a retention policy, not by consumption
Natural fit	Task distribution — jobs that must run once	Event distribution — facts several parties need to know

Decoupling

"How are producers and consumers decoupled in a pub-sub system?"

Producers don't know who'll end up reading their information. They just send it to the system, and the consumer reads it. The system acts as a decoupling layer between producers and consumers.

Producers are not affected by slow consumers, the number of consumers, or consumer failures. We can scale them independently.

Three independences, and they are worth enumerating separately

That quote packs three distinct guarantees, and naming them individually is more convincing than saying "it's decoupled":

Immune to slow consumers. A subscriber that takes ten seconds per message does not slow the publisher down by a microsecond. Compare a direct call, where the publisher inherits the slowest callee's latency.
Immune to consumer count. Publishing to one subscriber costs the same as publishing to a thousand. The publisher's work is O(1) regardless of fan-out — provided the system is designed so it doesn't do O(N) work either, which is exactly what Lesson 4 gets wrong.
Immune to consumer failure. A subscriber crashing does not fail the publish. In a direct-call architecture, one broken downstream service breaks the upstream one.

The general principle from the Distributed Messaging Queue chapter applies unchanged: the producer's obligation ends at "the message is durably stored."

Motivation

Distributed systems often rely on vast hardware infrastructure. Pub-sub systems enhance scalability by enabling asynchronous communication. This pattern decouples producers from consumers, allowing them to operate and scale independently. Consequently, engineers can add or remove components without disrupting the wider system.

'Add or remove components without disrupting the system' is an organizational property, not just a technical one

This is why pub-sub dominates microservice architectures, and it is worth being able to articulate.

When the order service publishes order.placed, adding a fraud-detection service that also wants those events requires no change to the order service — no deploy, no code review, no coordination between teams. The new subscriber just subscribes.

Under direct calls, the order service would need a new outbound call, which means a change, a deploy, and a conversation. Pub-sub moves integration from a code change to a configuration change, which is why teams that ship independently gravitate to it.

The cost is that nobody can easily answer "who consumes this event?", and removing a field from a message becomes frightening because the publisher genuinely does not know who depends on it. That is the trade, and it is real.

Key takeaway

A queue message is processed by exactly one consumer; a pub-sub message is read by every subscriber. Everything else follows: deletion is driven by retention rather than consumption, storage becomes a log, and adding a subscriber requires no change to the publisher.

Interview signal by level

Level	What a strong answer sounds like
L4	"Publishers send to a topic and subscribers receive the messages."
L5	States the difference precisely: "in a queue exactly one consumer processes each message; in pub-sub every subscriber gets its own copy — so adding a consumer splits work in one and duplicates it in the other."
Staff+	Draws the architectural consequence: "because the system can't know when the last subscriber has read, consumption can't drive deletion — retention does. That's why pub-sub storage is a log with per-consumer offsets rather than a queue. And the publisher's cost has to stay O(1) in subscriber count, which rules out the obvious copy-per-subscriber design."

Next: what people build with it, and what we're required to support.