Chat App | WhatsApp | Facebook Messenger | System Design

in this video I'll design a chat app like Facebook Messenger or WhatsApp so let's get started following our regular system design template let's first figure out the key functional requirements of a chat application a regular chat application should have a one-on-one chat it should have a feature of group chat a read listed feature which means when you are sending messages to someone else you should be able to get the double tick mark you should be able to see the online status or share your online status with others there should be a provosting of notification that is if there is a new message waiting for you in your chat there should be a pop-up notification and then you should be able to share multimedia data such as pictures videos give files and whatnot coming to the system requirements or the technical requirements one of the first things the most important thing for any real-time chat application or a real-time let's say stock broker application is low latency low latency is must for any real-time chat the system should be also highly reliable and available system should be able to serve both mobile and desktop clients that is web interface and the system should have storage for chat history the system we design should be also able to handle huge amount of data with text photos videos Etc it also needs to have end-to-end encryption and finally the connection should be client initiated then server initiated here we are not using HTTP protocol because the user needs to send a request to the server and once a response is received from the server then the connection is close it means every message needs to wait for the full transaction between server and client so the websocket protocol is used here because the connection is not closed immediately in fact here we are using the term websocket Handler which will be connected by the user you can think of websocket Handler as a lightweight server which keeps an open connection with all active users now having said about the limitation of HTTP protocol there is still a way to use HTTP to get our desired Behavior there is a concept of long polling in HTTP wherein the server keeps the client Connection open until a timeout or threshold has reached you can check out my short video on Long polling versus websockets to get a better understanding speaking of capacity planning it requires feedback from your interviewer in fact sometimes they ask you to skip this part and do the actual design and you don't need to spend too much time in this section however I would like to get some numbers out here so in terms of traffic estimation let's assume that we are dealing with a total of 500 million active users and on an average a user is sending 30 messages per day so the total messages per day is basically 50 million into 30 which is 1500 billion or 1. 5 billion messages per day is equal to 1. 5 billion by 3600 into 24.

that is around 18 000 messages per second as far as the storage is concerned the total messages per day we saw is 1. 5 billion considering each message is on average of 50 kilobytes the total storage required to store all the messages would be 1. 5 billion into 50 KB which is about 75 petabytes of data the only two API calls I can think of is send messages and get messages so when you are sending messages you send the user ID the receiver user ID and the text you want to sign and when you are getting the messages you get by user ID the screen size or before timestamp just remember the API calls we are talking about here is from the user standpoint that is the user machine will either send a message or it will receive a message given our functional and system requirements now let's proceed and Define all the services that will allow us to meet all our requirements will have a messaging service a relay service a group service a session service a last scene service and an asset service now let's talk about them individually at a high level starting with messaging service so when a user say user a wants to send a message to user B he sends a request to the messaging service with the ID of user B now before this user a establishes a persistent connection to the messaging service via websocket protocol because like we discussed earlier it's a bi-directional connection now in a traditional HTTP protocol the client needs to send a request every time when it requires some response but in websocket protocol the server can respond without any client request to be made messaging service identifies the user B via session service and sends the message accordingly so how does session service works whenever a user connects to the messaging service the messaging service tells the session service in which server the user has established the connection which is stored in a database more likely a nosql database since you don't have any scope for relations between the data later this information is used to send messages to the other end now what if the user B is offline in such cases we need to temporarily store the message to deliver it lately message service forwards this message to the relay service in the occasion when the user is offline the relay service will store the unsigned messages the from and the two user ID in a database like Cassandra the last scene service is used to store the timestamp of each user this information is based on logging of each user activity the client-side application should be intelligent enough to identify the difference between the user activity and the application activity itself and sends a signal to the app server this information can also be used to show the online status of the users Asset Services used to store and retrieve multimedia files in an object-based storage or a blob store like AWS S3 bucket and finally we have a group messaging service which is more like the messaging service except we need to publish the message to all the users associated with the same group ID this service will rely on the session service to identify the server to which each user is connected to now compared to other services group messaging service is fairly complicated and so we'll have a separate section to discuss more about group messaging so let's move on to the database schema now the choice of database here can be rdbms since we are dealing with more relations here but again you know based on the situation we can have a hybrid database with nosql in some cases which I kind of mentioned earlier so speaking of database schema we'll have users with Fields user ID username and same apical contact number and then we'll have groups and each group will have its own group ID and the user ID of the user part of that group then we have unsent messages with Fields message ID sent from ID sent to ID the content or the media URL say if you are sending messages such as video messages or PNG files you send the location of that PNG file in the form of media URL and the timestamp you can also have a last scene table with a user ID and this timestamp and finally you have the sessions table which basically maintains mapping of user ID with a server ID what we discuss until now was how a personal chat works on a system like WhatsApp but what about group chats for every group Creator will have a new group ID and this group ID will have a mapping to all the users who are in the group that is in the group mapping database now groups will behave a little different from users because websocket handlers won't keep track of groups it just tracks active users so when user a wants to send a message to Group 1 websocket Handler 1 gets in touch with message service message service will store the information to a queue or Kafka topic automation such as which user is sending word message to which group basically the message service will act as a Kafka producer and then we'll have group message Handler as our Kafka consumer which will be listening to the Kafka topics so whenever the message service posts a new message to Kafka topic that is user a is sending this message hello to group 1.