What Pub-Sub Is, and How It Differs From a Queue
In one line: 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.
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.
Why the social-media example is the right one to remember
It makes the fan-out ratio visceral. One write by the publisher becomes N deliveries, where N is the follower count — and N is wildly variable. A typical user has hundreds of followers; a celebrity has tens of millions.
That asymmetry is the entire engineering problem. The write side is trivial and the read side is unbounded, so every design decision in this chapter is really about how to serve N readers without doing N times the work. Lesson 4 shows the design that fails precisely because it does exactly that.
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 |
Read the third row carefully — it is the consequence people miss
In a queue, consumption is what destroys a message. In pub-sub it cannot be, because the system does not know when the last subscriber has read — subscribers arrive and leave, and some may not be connected right now.
So message lifetime must be decided by something other than consumption: a retention policy, covered in Lesson 5. That single shift is why pub-sub storage looks like a log rather than a queue, and why Lesson 6's offsets exist at all.
If an interviewer asks how the two differ, lead with "a queue message is consumed once; a pub-sub message is read independently by many, so deletion is driven by retention rather than by reading." That answer contains the whole architecture.
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 message-queue design 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.