Publisher-Subscriber Model — System Design/Architecture

Issues that the Publisher-Subscriber model solves

Imagine a case where there is one service calling multiple different services which in turn call other services. We will call the first service as sender service and the other services as receiver services because they are receiving the call from the sender service.

1. In the above scenario there’s a tight coupling between the sender and receiver services. The sender service needs to know information about the receivers and any change in the receiver would require a change in the sender service as well. It is obvious this architecture is not scalable! If we don’t care that the sender needs to know who the receiver is — publisher subscriber model is the solution.

Note: Coupling is the degree of interdependence between software modules; a measure of how closely connected two modules are; the strength of the relationships between modules.

Publisher Subscriber Model

The publisher-subscriber model allows messages to be broadcast to different services. These services would have subscribed beforehand to receive such messages and are called subscribers. The service sending out messages is called a publisher. The publisher actually sends out messages to a message broker (like kafka, redis, rabbitmq etc.) who then takes the responsibility to broadcast these message. There are various channels/topics to which publishers can send messages. The subscribers can subscribe to certain channels/topics to receive messages which are relevant to it.

You also have the option of creating some type of message retention policy in the message broker itself (based on storage or time limit) setup in your architecture to take care of cases if certain subscribers go down.

How is Publisher Subscriber model different from message queues?

Both publisher subscriber model and message queues are examples of event driven architectures. In a Message Queue the sender usually knows who the receiver is and one message is consumed by exactly one service whereas in Publisher Subscriber model, for a message there can be a lots of subscribers, and the sender does not care/need to know to whom the message is being sent.

Why should Publisher Subscriber Model be used ?

Publisher Subscriber Model is an event driven architecture which makes use of async calls. Let’s look at some advantages of publisher subscriber model over the case if we normally call the receiver functions.

Disadvantages of the Publisher Subscriber Model

The main disadvantage of the publisher-subscriber model is in maintaining the consistency of data. For example, if there is one publisher and multiple subscribers. If one subscriber goes down and does not receive a message. Ideally, to maintain consistency you would not want the other subscribers to act on that message but the publisher-subscriber model does not take care of it, and hence cannot be used in a system that requires consistency.

Most of the social media platforms make use of the publisher-subscriber model where whenever an account posts a new picture or tweet, all its follower accounts are subscribers who get information about this new post/tweet. Most of the cloud service providers like AWS, Google Cloud, Microsoft Azure, etc. have their own versions of event-driven message brokers which can be used directly by the application.

And that's a wrap! Hi, I am Gourav Dhar, a software developer and I write blogs on Backend Development and System Design. Subscribe to my Newsletter and learn something new every week - https://thegeekyminds.com/subscribe