Pub-Sub Model

Overview

The Publish-Subscribe (Pub/Sub) model is a messaging pattern where senders (publishers) categorize messages into classes (topics) without knowing if there are any receivers (subscribers). Subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are.

🧠 Mental model: Think of it like a newspaper subscription. The newspaper (publisher) prints the sports section (topic) and sends it out. You (subscriber) receive it because you subscribed to sports, but you don't talk directly to the journalist, and the journalist doesn't know you personally.

Key Concepts

Decoupling

Pub/Sub provides three dimensions of decoupling:

Space decoupling: Publishers and subscribers do not need to know each other's IP addresses or identities.
Time decoupling: Publishers and subscribers do not need to be active at the same time. The broker holds the message (temporarily or persistently) until subscribers consume it.
Synchronization decoupling: Publishing a message does not block the publisher's thread, and receiving a message happens asynchronously for the subscriber.

Topics and Fan-out

Messages are published to Topics. When one message is sent to a topic, the broker duplicates and pushes (or allows pulling of) that message to every active subscriber of that topic. This is called the Fan-out pattern. It allows a single event (e.g., "User Registered") to trigger multiple independent actions (e.g., Send Welcome Email, Create Profile in DB, Send Analytics Event) simultaneously.

Aspect	Message Queue (P2P)	Pub/Sub
Delivery	1-to-1 (One consumer gets the message)	1-to-N (All subscribers get the message)
Message Retention	Deleted after successful consumption	Retained until all subs consume (or TTL expires)
Use Case	Task distribution, load balancing workers	Event broadcasting, microservices choreography

Trade-offs

Pub/Sub enables highly decoupled and scalable architectures (like Event-Driven Architecture), but it trades off traceability. Because a single publisher action can fan out to dozens of subscribers, tracking the flow of a business transaction requires distributed tracing (like OpenTelemetry) and correlation IDs. Additionally, ensuring messages are processed strictly in order across a massive fan-out is notoriously difficult and usually avoided.

Interview Tips

If a design requires notifying multiple distinct systems about a single event, explicitly draw a Pub/Sub topic to show you understand Fan-out.
Mention popular technologies: Amazon SNS, Google Cloud Pub/Sub, Kafka (which blends queueing and pub/sub via consumer groups).
Always pair Pub/Sub with idempotent consumers, as brokers guarantee at-least-once delivery, meaning duplicates will happen.

Summary

Pub/Sub decouples publishers and subscribers in space, time, and synchronization.
Messages are sent to Topics and broadcast to all interested subscribers.
It enables the Fan-out pattern, where one event triggers multiple independent reactions.
It heavily relies on brokers to manage subscriptions and message routing.
Traceability and strict ordering are the main challenges in heavily decoupled Pub/Sub systems.