Embedded Files
- Introduction
Designing a chat system helps understand several components of an architecture. In this post we are mapping all the components using AWS services. In real life we would definitely using different components from outside AWS and hence this is mostly a theoretical exercise
1.1 Feature and Functionalities
1.1 Feature and Functionalities
There are several attempts to explain the chat system design on various publicly available forums. The feature functionalities are more or less known. So for MVP this will be the feature:
MVP Features
1-1 Chat
Ability to chat from both mobile and web
Send message even if the person is offline
Show online offline status
Message has 100 character options
Notifications on the chat message delivered, read, etc
login and logout to chat application
1.2 Back of the envelop calculations
1.2 Back of the envelop calculations
1.2.1 Message storage
Total number of user :1 Bn. At any point of time , let's assume 50% of users are online, i.e. 500 Mn users.
Size of individual messages : 140 character. Assume 10 messages are posted per day per user
Total size to store the messages per day:
500Mn x 10 x 140 bytes= 350000 Mn Bytes= 350 Bn Bytes=3500 Gb
For 5 years : 3500 X 365 X 5 = 6387.5 TB ≈ 6388 TB ≈6.3 PB
(We have considered the number of users to be static, but growth of user base with 10% percent user growing per year can also be incorporated)
1.2.2 Metadata Storage:
We need to store data related to users: for example:
name, phone number, online/ offline status, id.
If we assume about 100 characters per field, storage required per user is : 4 x 100 = 400 character.
For 1 Bn user, 400 bytes x 1 Bn = 400 Bn Bytes= 400 GB.
1.2.3 Query per second calculations:
We discussed earlier that 500 Mn users are online all the time. So QPS = 500Mn x 10 / (24 x 60 X 60) = 57870.37≈ 57870
Peak QPS = 2 X 57870 = 115740
1.2.3 Latency Requirements
We are assuming that the low latency requirement for chats. Anything less than 1 second is low latency. We will revisit this section again later once we have the initial high level design.
2. High Level Design
2. High Level Design
2.1. Context Diagram
The chat service at highest level can be thought of server which facilitates conversation between sender and receiver
2.2.Container Diagram
High level design with some of the basic features are shown in the diagram below. There are several components here.
Route 53 : Amazon DNS server to register and maintain the websites. For the chat website the DNS entries will be made so that it points to the same server.
User groups: Chat service is accessible from both mobile as well as web browser ( laptop)
ALB: Application load balancer: The job of the ALB is to route the service to the available servers based on load and performance.
Utility API service:
The API server has bunch of important functions:
Login
Sign Up
Profile Change
Receive the call from the user and find out which server is available and the target recipient is online
AWS cognito
Amazon Cognito lets you easily add user sign-up and authentication to your mobile and web apps.
Amazon EMR ( Apache zookeoper).
Apache zookeeper keeps track of the servers that are available to process the messages.
Chat Server
Chat server available the process the messages. They will facilitate sending and receiving of messages
ID Generator
Generates unique IDs for each and every messages. If the messages are being stored in a SQL DB then an auto incremented index value can be used. For storing the chat messages, however, a SQL DB is not appropriate as the chat messages because of the unique need of the chat service. A more appropriate service is key value store based database. More on this covered in 11. For a KV based storage there are no auto increment function.
Notification Server
Message Queue
Message Storage
Receiver Chat Server
Recipient
Attributions
Attributions
Comment
Google Sites
Report abuse