Chat App System Design

4 min readNov 7, 2021

Hi all, this article basically explains the general idea of how an app like WhatsApp can be designed. This is a very abstract design just to get an idea. Each component can have it’s own discussion in detail. This article will give you a kick start.

Let’s first gather some basic requirements for a chat application.

Functional requirements

One-one chat
Group chat
Read receipt
Online status
Push notifications
share multimedia
Multi device support

Non functional requirements

Low latency
Highly available
Highly scalable

Capacity planning

These are self assumptions that can vary in real time chat applications.

Traffic estimations:

Total active users: 500M

On average a user sends 30 messages per day.

Total messages per day= 500M*30=1500M=1.5B

msgs per day= 1.5B/3600*24=18k msgs per sec

Storage estimations:

Total messages per day= 1.5B

considering each message is on an average of 50 KB. Total storage required to store all messages= 1.5B * 50kb= 75pb

Messages are not going to be stored. Let’s say 1: 10 of the above data is for undelivered messages. And we are going to store undelivered messages only for 30 days.

Storage required for undelivered messages for one day= 75pb/10=7.5pb

Messages in 30 days= 7.5 PB * 30= 225PB

Basic API Services

Send_Message(sender_userID, reciever_userID,text)

Get_Messages(user_Id, screen_size, before_timestamp)

High level Design

Chat workflow

Messaging Service

when User A wants to send message to User B , he sends a request to the messaging service with the ID of User B. Before this ,User A establishes a persistent connection to the messaging service via web socket protocol because it is a bidirectional connection.

In a traditional HTTP protocol the client needs to send a request every time when it requires some response. But in web socket 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.

Session service

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 ‘No SQL’ database since we don’t have any scope for relations between the data. Later this information is used to send messages to the other end.

Relay Service

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 which will store the unsent messages with the from and to user ID in a database like Cassandra.

Last seen Service

The last seen service is used to store the timestamp for 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.

Group messaging service

This 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.

Asset Service

Asset service is used to store and retrieve multimedia files in an object based storage like AWS S3 bucket.

DB Schema:

The choice of database can be RDBMS since we are dealing with more relations here. But based on the situation we can have a hybrid database with NoSQL in some cases which I have discussed above.