Publish/subscribe (pub/sub) is a messaging pattern where a publisher sends one message and every interested subscriber gets a copy. The publisher has no idea who’s listening — it just announces “this happened” and walks away.
In simple language — a queue is a direct message to one worker; pub/sub is a group announcement that everyone subscribed hears.
Queue vs pub/sub — the one difference
This is the distinction interviewers love. Both are async messaging, but the fan-out is opposite:
The middle box in pub/sub is a topic — a named channel like order.placed or user.signed-up. Publishers send to the topic; subscribers register their interest in the topic. The topic is what lets N publishers and M subscribers connect without knowing each other.
// publisher — announce that something happened, don't care who listens
await sns.publish({ topic: "order.placed", message: { orderId: 42 } });
// three independent subscribers, each doing their own thing
onEvent("order.placed", sendConfirmationEmail);
onEvent("order.placed", decrementInventory);
onEvent("order.placed", updateAnalytics);One order.placed event, three reactions — and the order service wrote none of that follow-up logic. That’s the magic.
Event-driven architecture
Event-driven architecture (EDA) takes pub/sub and makes it the backbone of the whole system. Instead of services calling each other directly (“hey inventory, decrement this”), a service just emits an event describing what happened (“an order was placed”). Other services react to events they care about.
The shift in thinking: nobody commands anyone. Services announce facts (“this occurred”) and interested parties respond on their own. The order service doesn’t orchestrate email + inventory + analytics — it just says “order placed” and those three services take it from there.
Think of it like a newsroom — a reporter publishes a story, and whoever’s subscribed (readers, aggregators, other papers) reacts however they want. The reporter doesn’t phone each reader.
The upside
- Loose coupling — publishers and subscribers don’t know each other exist. We add a new subscriber (say, a fraud-check service) without touching the publisher. Massive for evolving a system.
- Scalability — subscribers scale independently. The email service can have 2 instances and analytics 20, all fed by the same event stream.
- Extensibility — new features often mean just “subscribe to an existing event”. No changes rippling across services.
The downside (be honest in interviews)
- Harder to trace and debug — with a direct call, the flow is a straight line we can follow. With events, one publish fans out to who-knows-how-many reactions across services. Answering “what happens when an order is placed?” now means mapping every subscriber. We lean on correlation IDs and distributed tracing to follow a request.
- Eventual consistency — because reactions happen asynchronously, the system is briefly out of sync. Right after
order.placed, inventory might not be decremented yet. Everything settles correctly given a moment, but “right now” the parts can disagree. We have to design for that instead of assuming instant consistency. - No built-in “did it work?” — the publisher gets no confirmation that subscribers succeeded. Error handling moves into each subscriber (retries, DLQs).
Where we see this
Amazon SNS is the textbook pub/sub service — publish to a topic, and it fans out to every subscriber (often SQS queues, so each consumer group gets its own durable copy). This SNS → SQS fan-out combo is a super common pattern: one event, delivered to many queues, each drained by its own service.
Interview soundbite
Pub/sub is one-to-many messaging: a publisher sends an event to a named topic and every subscriber gets a copy — versus a queue, where a message goes to exactly one consumer. Event-driven architecture builds a whole system on this: services emit facts (“order placed”) instead of commanding each other, and interested services react on their own. The wins are loose coupling and independent scalability; the costs are harder tracing/debugging and eventual consistency, since reactions happen asynchronously.