Point-to-point messaging in scaled applications?

Question

After you sent / sent a chat message like whatsapp, I came across the fact that they use a queue based messaging system. I'm just trying to determine what might be the high-level design of this function.

HLD for understanding: - Tell friend 1 and friend 2 online. Friend 1 established an HTTP connection to web server 1, and Friend 2 established an HTTP connection to web server 2. Friend 1 sent a message to friend 2.

Now, as soon as the message arrives at web server 1, I need to send the message to web server 2 so that the message can be dropped back to friend 2 through an already established web connection.

I believe that distributed user java queues can be used here to distribute messages from one server to another. As soon as the message arrives on one server, it will redirect it to the distributed queue (distribute the queue due to load balancing and high availability) with the message contents, fromUserId, toUserId. There will be a listener queue in the queue, which will see the destination address userId of only poppedIn messages and find on which the user userId of the web server is active. If the user is active, pull out the message and click on it to the client, otherwise save it in db so that it can be pulled out once on the network. To find out which user is active on which server, we can save the treemap with userId as key and value as serverName for efficient search

The actual design should probably be more complex / scalable than the one above. I would like to know if this is the right direction for scalable chat?

I also think that for such a scalable application, you need to have several distributed queues instead of one. But if we have several distributed queues, how will the system ensure the delivery of FIFO messages through distributed queues?

Answer 1

I would like to know if this is the right direction for scalable instant messenger chat?

Developing this application using message queues has the following advantages:

• Client-server isolation and crash reduction: queues can gracefully handle traffic peaks by simply having a temporarily increased queue size that will return to normal until normal traffic is back (or any temporary glitches were fixed)
• In a messaging application, clients (mobile phones) can be offline for a long time. As a result, synchronous design will not work because clients may not be available for message delivery. However, with an asynchronous design, as with message queues, the responsibility for delivering messages is on the client side. As a result, the client can poll for new messages as soon as it goes online.

So yes, this design can be quite scalable in terms of performance and usability. The only thing to keep in mind is that this project will require a separate queue for each user, so the number of queues will linearly scale with the number of application users (which can be a serious problem for financial and scalability).

But if we have several distributed queues, how will the system ensure FIFO message delivery through distributed queues?

Many queues, either open-source (rabbitMQ, activeMQ) or commercial (AWS SQS), support FIFO ordering. However, the FIFO guarantee within the queue is not enough, because messages sent by one client can be delivered to the queue in a different order due to problems with asynchronous network (if you do not use a single, unallocated queue and TCP that guarantees custom delivery).

However, you can implement a FIFO order on the client side. Following this approach, messages will include a timestamp that each client will use to sort messages when they are received. The only side effect is that the client could see the message without first seeing all the previous messages. However, when previous messages appear, they will be displayed in the correct order in the client user interface, therefore, as a result, the user will see all messages in the correct order.

Answer 2

Would like to know if this is the right direction for scalable chat messenger? 

I would prefer a slightly different approach. Your ideas are correct, but I would like to add a little more to the same. I happened to create such a chat messenger a few years ago, and it should have looked like a watsapp. I am sure that when you googled, you would come across the XMPP Extensible Messaging and Presence Protocol. we used openfire as a server supporting connections. Concept that you explained where

 Say Friend 1 and Friend 2 are online . Friend 1 has established HTTP web connection to web server 1 and Friend 2 has established HTTP web connection to web server 2. Friend 1 send the message to Friend 2. 

called federation, and openfire can run in federated mode. After reading your comments, I came across one queue at a user point. I am sure that you already know that this approach is not scalable because it is very resource intensive. A good approach would be to use an Actor structure such as an aka. Each actor is similar to a stream of light weight in java, and each actor has a mailbox. therefore, in this case it will take care of the messaging.

So, your script turns into Friend 1, opens a connection to the openfire xmpp server and initializes the actor Friend 1. When he types a message, he is transferred to the actor Friend 1 in-box (each actor in akka has Inbox in his memory). This is reported to the xmpp server. The server has its own database, and since it integrates with other xmpp servers, it will try to find if friend 2 is online. The xmpp server will store the message in its db until it goes online. When friend 2 establishes a connection with any of the xmpp servers, the creator of friend 2 is created, and his presence extends to all other servers, and server xmpp 1 will notify friend 2. Friend-2-incoming user will receive a message

Additionally: there is also the possibility of receiving a receipt. As soon as Friend2 reads the message, the delivery receipt can be sent to friend 1 to indicate the status of the message that has been read, unread, delivered, not delivered, etc.