Publish/Subscribe is a messaging pattern where publishers send messages to a topic and subscribers receive those messages without direct coupling between them.
Modern systems often need components to react to events (e.g., new data, user actions) without tightly coupling the components. Pub/Sub enables this loose coupling, which is essential in microservices, event-driven, and real-time systems.
Use it when you want to broadcast messages to multiple independent consumers without the publisher needing to know who they are.
You need to know
Decoupling: Publishers don’t know who the subscribers are, and subscribers don’t care who sent the message. This makes the system more flexible and scalable.
Message Delivery: A broker (e.g., Kafka) handles message delivery, persistence, ordering, and potentially retries or acknowledgments.
Fan-Out Support: One message can trigger multiple subscriber actions, useful for audit logs, notifications, analytics, etc., from a single event.
Popular technologies
Apache Kafka - Distributed event streaming platform ideal for high-throughput use cases.
Google Cloud Pub/Sub - Fully managed messaging service for real-time analytics and microservices.
RabbitMQ - General-purpose message broker supporting various messaging patterns, including Pub/Sub.
Like posts like this?
Every week, you'll get a new system design concept, broken down like this one.
Free subscribers also get a little bonus:
🎁 The System Design Interview Preparation Cheat Sheet
If you're into visuals, paid subscribers unlock:
→ My Excalidraw system design template – so you have somewhere to start
→ My Excalidraw component library – used in the diagram of this issue
No pressure though. Your support helps me keep writing, and I appreciate it more than you know ❤️