Overview
Publish/subscribe (pub/sub) is a messaging pattern where publishers send messages to a topic without knowing who receives them, and every subscriber to that topic gets its own copy. Unlike a work queue, where each message is handled by one consumer, pub/sub fans a message out to many independent consumers.
Pub/sub is the backbone of event-driven architectures: an OrderPlaced event can trigger email, shipping, analytics, and fraud checks, each owned by a different team, without the order service calling any of them. New subscribers can be added without changing the publisher.
The author publishes one issue; every subscriber gets a copy. The author does not know or care how many readers there are, and new readers can subscribe anytime.
When to use it
- One event must trigger several independent reactions.
- Decoupling teams and services.
- Real-time notifications and live updates.
- Broadcasting cache invalidations or configuration changes.
Where it shows up in interviews
Recognize it when: an event matters to several services.
- Design an e-commerce order pipeline
- Design a notification system
Recognize it when: push changes to many clients.
- Design a live sports score app
- Design a chat system
Where it is used in real software
SNS topics fan out to multiple SQS queues, one per consuming service.
Global managed pub/sub with push and pull subscriptions.
Lightweight, fire-and-forget pub/sub used for chat presence and cache invalidation.
Key terms
- Topic
- Named channel that publishers send to.
- Subscription
- A consumer's interest in a topic; each gets every message.
- Fan-out
- Delivering one message to many subscribers.
- Message filtering
- Subscribers receive only messages matching attributes.
- Durable subscription
- Messages are retained for subscribers that are offline.
How it works, step by step
- 1Publisher emits an event
OrderPlaced {orderId, total}.
- 2Broker stores it on the topic
Durably, if configured.
- 3Each subscription gets a copy
Email, shipping, and analytics each receive it.
- 4Subscribers process independently
One failing does not affect others.
- 5Add subscribers anytime
No change to the publisher.
STEP 1The order service publishes OrderPlaced once.
Queue vs pub/sub
How messages are distributed
| Aspect | Work queue | Pub/Sub |
|---|---|---|
| Receivers per message | One consumer | Every subscriber |
| Purpose | Distribute work | Broadcast events |
| Adding a consumer | Shares the load | Gets its own copy of everything |
| Example | Resize images | Notify email, shipping, analytics |
NOWAspect: Receivers per message | Work queue: One consumer | Pub/Sub: Every subscriber
Many systems combine them: a topic fans out to one queue per service, and each service's workers compete on its queue.
Implementation
import { SNSClient, PublishCommand } from "@aws-sdk/client-sns"; const sns = new SNSClient({}); // Publisher: does not know who is listeningawait sns.send(new PublishCommand({ TopicArn: process.env.ORDERS_TOPIC_ARN, Message: JSON.stringify({ type: "OrderPlaced", orderId: "o-981", totalCents: 4599 }), MessageAttributes: { type: { DataType: "String", StringValue: "OrderPlaced" } },})); // Each service subscribes its own SQS queue to the topic (infrastructure as code),// optionally with a filter policy such as: { "type": ["OrderPlaced", "OrderCancelled"] }Complexity and performance
Broker handles fan-out.
Per message.
Trade-offs
Publishers do not know consumers, which makes it hard to see who depends on an event; maintain an event catalog and schemas.
Fire-and-forget pub/sub (Redis) loses messages for offline subscribers; durable systems retain them.
Variants and related techniques
Subscribe by topic name, or by filters on message content.
Kafka topics retain messages; each consumer group reads at its own offset.
Common mistakes
- Breaking event schemas.
Fix: Version events and keep changes backward compatible; use a schema registry.
- Using pub/sub for commands that need a response.
Fix: Use request-response or a queue with a reply channel.
Interview questions
When would you use pub/sub instead of direct calls?
When an event matters to several independent consumers, when the publisher should not depend on their availability, or when new consumers will be added over time.
How do you fan out to services reliably on AWS?
Publish to an SNS topic subscribed by one SQS queue per service; each queue buffers messages durably and has its own retries and dead-letter queue.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Design the event flow for an order | Easy | Fan-out. |
| Design a live notification system | Medium | Topics and push delivery. |