How to Develop a Messenger Application From Scratch: System Designing Guide for Messenger Like Chat Systems Part 2

Develop a messenger app from scratch

This is the part of already discussing part of developing messenger application from the scratch system so if you not read the first part of this tutorial click here Messenger Application From Scratch part 1 and after this tutorial click here to read the 3rd part of How to Develop a Messenger Guide for Messenger Like Chat Systems

High-Level Architecture Design analysis:

At a significant level, we will require a Node server i.e. nothing but the Chat Server which will be the focal piece, organizing all the test/image communications between clients. At the point when a client needs to message to another client, they will interface with the Node server and send the message to the Server; the node server at that point passes that message to the next client and furthermore stores it in the HBase/Cassandra base

The detailed workflow would look like this:

User-X sends a message to User-X through the chat server.
The server stores the message in its database and sends the message toUser-X.
The server notifies User-X that the message has been delivered successfully to User-Y.
The server receives the message and sends an acknowledgment to User-X

Detailed component design for Facebook messenger

I am going to explain here in this blog about the system designing of Facebook Messenger. You must have used this messenger service.

So, with Facebook Messenger, what they do is they keep all of the data in the messaging service. Whatever you chat/message, they keep all that information in their service and in their system forever until you go ahead and delete them. But in WhatsApp, what they do is as soon as the other party receives a message, they just delete the message. So, they only keep the message as long as the other party has not received the message.

· With Facebook Messenger, if Facebook wanted, they could read those messages unless and until you turn on end-to-end encryption. While WhatsApp has end-to-end encryption, which means that the middle tier or the services in between cannot read your messages. So, what I am going to explain the design here is Facebook Messenger. So, these are the main features:

· One to One Chatting(how the other person is going to receive your messages)

· Online/Sent/Read(we need the ability to show that the other person is online and when the message is sent and when the message is read by the other party)

· Sending Images and other files. (we need the capability to send pictures or other big files)

· Database Design

· Security

Here, in the below diagram(Diagram -FB) given in the last, user X talks to the load balancer. A load balancer can operate at level 3, level 4, or level 7. Load balancer talks to one of the nodes behind Node1, Node2, and Node 3. Most of the time they are stateless and what they do is they do the bulk of the work which is serving requests for the user or talking to the database or talking to the Redis cache.

You can have a NoSQL database (HBase or Cassandra or Mongo DB) which is a very popular database, but you could use any other database and for the DistributedCache, I am using Redis Cache here which is going to store temporary information for the user.

The next scenario is about what happens when the user logs in for the first time into Facebook. Let me first explain to you about the HTTP architecture.

HTTP Architecture:

HTTP is a request/response architecture where the client sends requests and the server sends a response back. The server cannot initiate the request to the client. So, what that means is that this architecture does not work very well with a chat application. Because if user Y has some data to send to user X and it sends data to the server and the server cannot initiate a request to the client because that's not how HTTP works. So, to overcome this drawback, we have a few alternatives and I've listed some of them here:

WebSocket(This is a fully bi-directional connection. Once user X is connected to the server both server and the client can initiate the request because it's bi-directional)

BOSH(is a bi-directional stream over synchronous HTTP. It works over HTTP and what it does is the user X, the client requests to the server and server holds on to that request till certain time has passed or until it has some new data at which point he will send a response back and then user X will instantly initiate a new connection/request to the server. So, that way if a server has some new data, it can send a response back at which point user X will again start a new request.

HTTP Long Polling(Here, the client can send an HTTP request to the server and if the server has some new information, then it responds with that information or it says that I do not have any information and then the client waits a certain interval of time and then client starts a new request.

So, from all the three, the WebSocket works the best for our scenario. One more thing with the WebSocket is that it has something like a sticky session where if a user X starts a request to the server and if the request went to Node1, then it's always the Node1which is going to be connected with user X.So, all the requests from user X will always end up at Node1 and you will know how we're going to use that to our advantage in this design.

Messenger Login and Messaging Service:

Next, let's go deeper into our messaging. you go to a browser; you type in your Facebook credentials AND Facebook authenticates that. Now, you are ready to send and receive messages and also the fact that you're online so let's see what happens here.

So, user X goes to a load balancer and the load balancer will pick one of the hosts (N1 or N2 or N3) based on FIFO or based on a number of connections or just based on the load average the hosts. so suppose, load balancer picks the N2 host. Remember this is a WebSocket connection, so it's bi-directional in nature. Both the server and client can initiate a request.

At this point, while user X is not sending any data, but they are just heart beating between them. So the Node 2 (N2) is managing user X. Why we need to constantly heartbeat because that way the server knows that user X is still there and also User X knows that the particular server is still in an online state.

So, heart beating information is going to be stored in the Redis cache. So, in Redis, we are going to store the user Xand then the server(here it is N2) who is managing the user, and then we’re going to store when was the last time this heartbeat was received. So it could be like October 29th at 5:10 p.m. and 33 minutes and then milliseconds. And every time N2 gets a new heartbeat from user X, it is just going to update that into Redis cache.

Why have used Redis here?

This is a distributed cache and it holds all the line memory and if you want you can also flush that to the hard drive. It's also master slaves and slaves can hold the same copies as masters. Most of the time slave has pretty much all the information which the master does. So, now the question is can you hold all this data in memory?

So, Facebook has got like 1 billion users and every host these days can easily have like a hundred gigabytes of So, holding 1 billion users information, it would not take more than 10 hours to hold such kind of information. We can easily hold all that information for all 1 billion users in memory. By keeping the data in memory, we have multiple advantages.

First when two writes occur and it is very fast and also if someone else needs to read that information about user X, then they can do it very quickly. So, that's why we're going to use Redis and it is going to hold all the information in memory.

After reading this tutorial click here to read the 3rd part of How to Develop a Messenger Guide for Messenger Like Chat Systems