Facebook/ WhatsApp/ Slack/ Discord

Almost everyone has at least one of the popular chat apps installed on their phones. Messaging services like Facebook Messenger, WhatsApp, Discord and Slack allow you to send and receive messages from other users. Different apps have different functions, but there are certain key features that are common in all of them.

Let’s design an instant messaging service that supports one-on-one chat between users through mobile and web interfaces. Depending on your requirements, you may design a system that supports group chats too.

How To Design A Messaging App

Designing a chat service is a popular interview question asked by companies like Facebook, Amazon and Twitter. As with any system design question, designing a messaging app can be a broad topic so it’s important not to address a single approach and start discussing it from the beginning.

Take a few minutes to explore what the interviewer wants you to design. List down the key features that your messaging app should have and then generate a customized system based on the requirements.

Outline The Key Features

Our messaging app should at the minimum support the following key features:

1. One-on-one-chat and group chats between users.
2. Allow users to send text, pictures, videos and other files.
3. Store chat history.
4. Show the online/offline status of users.
5. Sent/delivered/read notifications.

List Down The Requirements

As of January 2021, WhatsApp supports 2 billion monthly active users according to Statistica. To build a system that can support such a large number of users, there are some additional requirements you will have to incorporate:

1. The service should be able to handle 2B users, with around 10B messages sent each day.
2. Real-time chatting with minimum latency.
3. The messaging service should be highly available, but consistency is of higher priority than availability in this case.
4. The system needs to be highly consistent. In other words, all users should see messages in the same order through any device they login from.

Expected Capacity

Estimating Message Storage

Estimating around 10B messages sent each day, with an average size of 140 bytes for each message, we’ll need around 1.4 TB of storage capacity for daily messages.

10 billion messages * 140 bytes = 1.4 terabytes

The above estimation assumes there’s no meta data and a single copy of messages is saved. In actual messaging applications, however, metadata along with other information are also stored. Messages are replicated across multiple caches for scalability and reduced latency.

Keeping our design simple, we’ll assume 1.4 TB of daily message storage. Now, assuming we store chat history for 10 years, we will need:

10 years * 365 days * 1.4 TB ≅ 5 petabytes

Storing Online/Offline Status

Messages aren’t the only data that is stored. In the case of Facebook Messenger, for example, the users’ statuses are also stored. However, these will not need to be saved in the database, just the memory cache.

Let’s assume that Facebook Messenger also has 2 billion monthly active users. Considering the real-world scenario, they won’t all be active at the same time. Let’s assume that half of them, i.e. 1 billion are active at a time.

If each entry takes 1 KB, you’ll need:

1 B * 1 KB = 1 terabyte of memory space in the distributed cache.

For a scalable service such as this one 1 TB of memory cache is reasonably affordable. The messaging service sends heartbeat timestamps to the cache. A user’s online presence will be confirmed by his/her presence in the cache with a recent timestamp.

Basic Architecture

For the most elementary architecture of the system, assume that there are two users, A and B who want to communicate with each other. In the ideal scenario, where A knows the address of B and B knows the address of A, they can each send information to the other at the known IP address.

High Level Architecture

Coming closer to the real-world scenario, consider clients A and B are part of a bigger network, which also facilitates millions of other users for the exchange of messages. Now, in such cases, it’s not feasible that the users know the IP addresses of other users. So instead of direct connection between the users, there has to be a server in between to manage the connections.

In a horizontally scaled system, there will be multiple servers that are a part of the messaging system that A and B want to communicate through. If A wants to send a message to B, it will connect to the server that’s free and has the capacity to serve the communication. Here’s where we’ll need a load balancer.

Click here to continue reading this lesson on Medium.