System Design Architecture : Publisher Subscriber Model

In the realm of software architecture, the Publisher-Subscriber (Pub-Sub) model stands out as a powerful and flexible pattern for building scalable and decoupled systems. This model is widely used in various applications, from real-time messaging systems to event-driven architectures, making it a cornerstone for modern software development.

In this blog we are going to study about Pub-Sub model, it’s working ,benefits and everything else. So let’s get started 🔥

What is Pub-Sub Model?

The Publisher-Subscriber model is a messaging pattern where publishers send messages without knowing who will receive them, and subscribers receive messages without knowing who sent them. This decoupling allows for more flexible and scalable systems, as components can evolve independently.

Let’s consider an example suppose Alice is interested in the updates from both Bob and Charlie, so she subscribes to their tweets by following their accounts. Bob and Charlie publishes their respective tweets. These tweets are sent to X’s backend system. Twitter’s backend system processes both tweets and delivers them to Alice’s timeline. Alice can now see updates from both Bob and Charlie in real-time, without either Bob or Charlie knowing directly about Alice’s interest or activity.

Bob and Charlie don’t need to know about Alice or manage the delivery of their tweets to her. They simply publish their messages, and Twitter handles the rest. So heere Bob and Charlie are publishers and Alice is subscriber.

Key Components of Publisher Subscriber Model

• Publisher: The component that generates and sends messages. Publishers are responsible for creating and publishing messages to a message broker or event bus.
• Subscriber: The component that receives messages. Subscribers register their interest in certain types of messages or topics with the message broker.
• Message Broker/Event Bus: The intermediary that facilitates the communication between publishers and subscribers. It receives messages from publishers and routes them to the appropriate subscribers based on their subscriptions.

Pub-Sub Model Working

The working of this model is very simple. The subscriber subscribes to one or more topics in which they are interested in to get the messages. At a time more than one publisher can publish message and then they send messages to specific topics (Topics are named channels to which subscriber has subscribed to). The subscribers get the messages through messaging queue. And this is how the model works.

• Step: 1 — Publishers create and send messages to the Pub/Sub system. They categorize messages into topics or channels based on their content.
• Step: 2 — Subscribers express interest in receiving messages from specific topics. They receive messages from topics to which they are subscribed.
• Step: 3 — Topics are named channels to which messages are published. Publishers send messages to specific topics, and subscribers can subscribe to one or more topics to receive messages of interest.
• Step: 4 — Message brokers are intermediaries that manage the routing of messages between publishers and subscribers. They receive messages from publishers and forward them to subscribers based on their subscriptions.
• Step: 5 — When a publisher sends a message to a topic, the message broker receives the message and forwards it to all subscribers that are subscribed to that topic.
• Step: 6 — This model allows for asynchronous communication between publishers and subscribers. Publishers can send messages without waiting for subscribers to receive them, and subscribers can receive messages without the need for publishers to be active.

Benefits

• Loose coupling between system components: The Pub/Sub pattern decouples communication logic and business logic, allowing the isolation of components. Isolated components make the system robust and keep the code maintainable.
• Better view of the system-wide workflow: The premise of the Pub/Sub pattern is simple, so Pub/Sub systems are easier for software architects to refactor and expand.
• Better & faster integration: Pub/Sub is programming language and communication protocol agnostic, which allows disparate components of a system to be integrated faster compared to legacy alternatives.
• Smooth scalability: Systems using Pub/Sub are scalable without the fear of breaking functionality because communication logic and business logic are separate entities. Software architects can redesign the message broker’s topic architecture without the worry of breaking the business logic.
• Guaranteed consistent reliability: The Pub/Sub pattern also helps in keeping the system reliable when features change. Pub/Sub supports asynchronous message delivery, which ensures reliable message delivery even when the message broker’s topic architecture changes.
• Builds elasticity: Pub/Sub systems are elastic because the business logic does not depend on the number of active publishers and subscribers at an instance. In other words, Pub/Sub systems can accommodate a surge in usage.

When to use this model?

Pub/Sub’s loose coupling, asynchronous nature, and inherent scalability make it an excellent solution for distributed systems with a high and fluctuating number of publishers and subscribers. You can use Pub/Sub for many different purposes, such as:

• Sending event notifications.
• Distributed caching.
• Distributed logging.
• Working with multiple data sources.
• Broadcasting updates (one-to-many messaging).
• Building responsive, low-latency end-user experiences like live chat and multiplayer collaboration functionality.

Implementing the Pub-Sub Model

There are several tools and frameworks available for implementing the Publisher Subscriber model. Some popular choices include:

1. Apache Kafka: A distributed event streaming platform that provides high-throughput, low-latency messaging.
2. RabbitMQ: A message broker that supports various messaging protocols, including Publisher Subscriber.
3. Google Cloud Pub/Sub: A fully managed real-time messaging service that allows you to send and receive messages between independent applications.
4. AWS SNS (Simple Notification Service): A fully managed messaging service that supports Publisher Subscriber messaging for microservices, distributed systems, and serverless applications.

Real Life Applications

• Event-Driven Architectures: The Publisher Subscriber model is a cornerstone of event-driven architectures, where systems react to events as they occur. This is common in microservices architectures.
• Real-Time Applications: Applications like live sports updates, financial market data feeds, and multiplayer online games use the Publisher Subscriber model to distribute real-time updates to multiple subscribers.
• Logging and Monitoring: Collecting logs and monitoring metrics from various sources and distributing them to analysis tools is a typical use case for the Publisher Subscriber model.
• IoT Systems: In Internet of Things (IoT) systems, sensors (publishers) send data to a central hub (message broker), which then distributes the data to various monitoring systems (subscribers).

The Publisher-Subscriber model is a versatile and powerful pattern that addresses many challenges in modern software development. By decoupling components, it enables scalable, maintainable, and flexible systems suitable for various applications. Whether building a real-time messaging app, an event-driven architecture, or an IoT solution, understanding and leveraging the Pub-Sub model can significantly enhance your system’s design and performance.

Thankyou 💚