From part-1 on we decided to choose a WebSocket network protocol for communication to simulate server-initiated connection. WebSocket connection initiated by Client. It is bidirectional and persistent. Though it is a persistent connection, a server could send updates to a client.WebSocket generally works even if a firewall is in place. This is because of the same port 80 or 443 used by HTTP/HTTPS.

High-Level Design

As we decided to use websocket for a chat so for other features we can use the traditional request/response method of HTTP(Rest API).

So Now the chat system is divided into three parts:- Stateless service, stateful service and third-party.

Stateless Service-> Manage user sign-up. login, user profile etc.

Stateful Service->Manage chat communication among users.

Third-party- Push Notification when the user is offline.

DataStore:

To Make a database choice - we have 2 types -SQL and No-SQL DB
RDMS for Stateless service for User Management. It can be scaled by using replication and Sharding technique.

But to maintain chat history data. Need to understand read/write the pattern.

Chat history has enormous data and users mostly check recent chats. But in some cases, users might want to search with a particular keyword and the chat system can navigate to a specific message.

So r/w = 1:1 in one -one chat

Random excess is expensive in RBMS.So we choose key-value stores to store messages. Facebook and Discord choose key-value stores for messages. Facebook is using HBase and Discord was using Cassandra but recently modified the architecture of Discord.

Key-value stores can easily be scaled horizontally and have low latency.

So high-level design with services and data store is

Final Design:

Please check out my blogs.