Their are various ways you can communicate with servers and get response from them in a certain way. The method we always and 80% of online websites works on is the Request Response Architecture. Whereas sometimes this architecture can become tedious and might fall short in specific use cases.

This Article is a deep dive into the Pub-Sub Architecture where we explore some other way of communicating with servers. Let's go.

Where does Request Response model breaks?

Suppose you have a Video Transcoding service just like Youtube and you use the Request Response model method for this service.

A Video Transcoding Service has these 4 major services:

• Upload Service

• Compress Service

• Format Service

• Notification Service

The above diagram shows how the Response Request Architecture breaks:

1. This Topology is tedious and too complex

2. Every Service or prior service is depend or waiting for the next service to be completed. Everything is dependent on each other.

3. User needs to wait a lot to get any response as the request itself is getting processed through multiple services.

How Pub-Sub Architecture is different ?

Publish-subscribe messaging, or pub/sub messaging, is an asynchronous communication model that makes it easy for developers to build highly functional and architecturally complex applications in the cloud. This type of communication is feasible when you have multiple process running and you need a more rapid way of execution of functions or processes.

Publish - Subscribe Model works on event based & topic based communication, where we make our services subscribe to a specific topic. This services then only run when there's a change in an event of that topic.

Pub-Sub has the following components:

1. Publisher

2. Subscriber

3. Topics

4. Messages

You can see from the below diagram that how the same services are running but using the Pub-Sub Model of communication. Here no services is dependent and we are even practicing De-Coupling as no services or requests are coupled into one single process.

/diagram

Let's understand this with some Node js Code:

Here we have a scalable chat application built with Redis, Socket.io and Kafka. We have implemented the Pub-Sub Model. I will show you some bits of the code and explain the code simultaneously.

Initialize the Publisher and Subscriber

Make the publisher to publish on "message" topic:

This is a socket code where we initialize socket connections and when the sockets are connected we publish the socket on the "message" event-topic with the message.

As we publish then we call the subscriber to subscribe the topic "messages" and then call an asynchronous request where if channel has some MESSAGES, then we emit the message event and the produceMessage function consumes the messages and passes it next to Kafka.

You don't need to worry about the produceMessage function, you can get the code from my repository in the end!

Subscribe to the topic & Consume the messages coming into Redis DB through Kafka.

Here as we are using Kafka for message consumption to scale our messaging app.

I will explain what the startMessageConsumer() function does:

• Starts consuming messages produced by the producer.

• Consumer subscribes to the topic: "MESSAGES"

This is how the Pub-Sub Model works in action and execution.

Difference between Message Queues and Pub-Sub

A message queue is another form of asynchronous communication used in server less and micro services and architecture. Messages are stored in the queue until they are processed and deleted. Message queues require the sender to know who they are exchanging messages with. Message ordering may also cause bottlenecks in the system.

In contrast, the publish subscribe (pub/sub) pattern allows for more flexibility. Several interested subscribers can receive messages simultaneously and asynchronously. Publishers don't need to know who the subscribers are. Message handling is more scalable and reliable, and it gives better performance.

Pro's and Con's of this model

Pro's

1. Scales with multiple receivers and servers

2. Great for micro services

3. Loosely coupled / Decoupled

4. Works while clients are not running

Con's:

1. Message Delivery Issues

2. Network Saturation

3. Complex

This is the end of the developer blog on how Pub Sub can be used for building fast, robust and scalable applications. A small initiative towards learning some advance stuff and documenting the journey in the same time.

Code: Repository URL

This article is more explained profoundly in Piyush Garg's Video

If you understood my explanation and liked the devblog, make sure you like this article ❤️and comment your thoughts !