Pub-Sub (Publish-Subscribe)
Understand event-driven messaging with topics, publishers, and subscribers for one-to-many message distribution.
Controls
Click topic buttons (t1/t2/t3) on each subscriber to toggle subscriptions.
Manual Publish
What's happening?
Publishers broadcast events to topics (channels). Every subscriber that has subscribed to a topic automatically receives a copy of each message. Toggle the colored topic buttons on each subscriber to subscribe or unsubscribe in real time. Use Manual Publish to push messages to specific topics and watch delivery fan out.
Why it matters?
Pub/Sub enables one-to-many messaging with loose coupling — publishers don't know who's listening. Unlike queues (one consumer per message), every subscriber gets their own copy. This is how systems like Google Pub/Sub, Kafka topics, and WebSocket rooms broadcast notifications, analytics events, and real-time updates to thousands of clients.
Why this exists
Pub-sub decouples event producers from event consumers through topics or streams. Producers publish once. Multiple subscribers react independently. This is powerful for event-driven systems, but requires careful thinking about ordering, replay, duplication, and consumer lag.
Fan-out is the core value
One producer can trigger analytics, notifications, search indexing, and billing without directly calling each system.
Consumers move independently
Each subscriber processes at its own speed, with its own failure handling and persistence behavior.
Events need contracts too
Loose coupling does not remove schema evolution problems. It just moves them into event design and consumer compatibility.
Key takeaways
- Pub-sub is for one-to-many event distribution.
- It reduces producer coupling, but increases event contract discipline.
- Consumer lag, replay, and ordering matter in real systems.
- Event-driven architecture is operationally powerful, not magically simpler.