Publish/Subscribe Pattern
The pub/sub messaging model: topics, subscriptions, fan-out, filtering, and how it enables event-driven architectures.
Point-to-Point vs Pub/Sub
There are two fundamental messaging patterns. In point-to-point (queue-based) messaging, each message is consumed by exactly one consumer — think of a task queue where multiple workers compete for jobs. In publish/subscribe (pub/sub) messaging, a message published to a topic is delivered to all subscribers of that topic. One event, many recipients.
| Dimension | Point-to-Point | Pub/Sub |
|---|---|---|
| Delivery target | One consumer (competing) | All subscribers |
| Primary use case | Task/work distribution | Event notification / fan-out |
| Coupling | Producer knows about queue | Producer unaware of subscribers |
| Examples | SQS, RabbitMQ default queue | SNS, Kafka topics, Google Pub/Sub |
| Scaling consumers | More workers = more throughput | Each subscriber group scales independently |
Topics and Subscriptions
A topic is a named channel. Producers publish events to topics. A subscription is a durable connection between a topic and a consumer — the broker tracks which messages each subscriber has received. When a new subscriber is added, it can optionally receive messages from the beginning of history (in systems like Kafka), or only new messages going forward.
Fan-Out Pattern
Fan-out is the killer feature of pub/sub. A single event from the order service simultaneously triggers email confirmation, inventory deduction, analytics recording, and loyalty point calculation — without the order service knowing any of these exist. Adding a new downstream action requires zero changes to the producer.
Real-world example: AWS SNS + SQS fan-out
A common AWS pattern: publish to an SNS topic, which fans out to multiple SQS queues — one per downstream service. Each service gets its own queue with its own retry and dead-letter configuration. This gives you the fan-out of pub/sub with the durability and per-service isolation of point-to-point queues.
Message Filtering
When a topic carries many different event types, consumers often only care about a subset. Message filtering lets subscribers declare what they want. AWS SNS supports filter policies on message attributes. Kafka consumers can subscribe to specific topics or use record headers. Google Pub/Sub supports filtered subscriptions with attribute expressions.
// AWS SNS filter policy on a subscription
// Only deliver messages where eventType = "order-placed" AND amount > 100
{
"eventType": ["order-placed"],
"amount": [{ "numeric": [">", 100] }]
}Durable vs Non-Durable Subscriptions
A durable subscription stores messages while the subscriber is offline and delivers them when it reconnects. A non-durable subscription only receives messages published while it is actively connected — messages published during downtime are lost. For production systems, almost always use durable subscriptions.
Competing Consumers Within a Subscriber Group
Pub/sub and point-to-point are not mutually exclusive. Kafka's consumer groups elegantly combine both: all subscribers in different groups receive every message (pub/sub fan-out), but within a group, each message is processed by only one instance (point-to-point load balancing). This is how you scale a subscriber horizontally while still getting full fan-out.
When to Choose Pub/Sub
- Multiple independent services need to react to the same event
- You want to add new downstream services without touching the producer
- You need event-driven architecture where services are fully decoupled
- Broadcast notifications (push to all connected users, all regional nodes)
Interview Tip
When an interviewer asks how you'd notify multiple services about an event, immediately reach for pub/sub. Key phrase: 'I'd publish to a topic so each downstream service subscribes independently — no coupling, and adding new services requires zero producer changes.' Then mention the SNS+SQS fan-out pattern for durability.