How to Develop a Messenger Application From Scratch: System Designing Guide for Messenger Like Chat Systems Part 1
How to develop a messenger application |
Designing Facebook Messenger
- Here, you are going to learn about designing an instant
messaging service like Facebook Messenger where users can send text
messages to each other through web and mobile interfaces.
- Facebook Messenger is a software application that provides to its users. Messenger users can chat with their Facebook friends both from cellphones and Facebook’s website.
Before jumping into Component
designing, first, think of what are the primary things to be concerned. Below is
the discussion factor for the Messenger System Designing by Java development services company.
- What are the requirements for the System Goals?
- Capacity Estimation and Constraints
- High-Level Design
- Detailed Component Design
- Online/Offline Messages Handling
- Storing and retrieving the messages from the database
- Load Balancing &Caching
Functional
Requirements:
- Our Messenger service must be capable of serving
one-on-one message communications between users or multiple users.
- Our system should be highly consistent which means the
users can see their old conversations or chat history in all the devices
without any data loss and the data is consistent across all devices.
- Messenger application should be capable of displaying
chat history or old conversations to the users by storing the Chat History
into the database.
Non-functional Requirements:
1. Users must have
registered himself/herself in the
messenger app for availing the messenger service
2. Our system
should be highly consistent that means the users can see their old
conversations or chat history in all the devices without any data loss and the
data is consistent across all devices.
3. Messenger
service you are going to design must be
highly available.
.
Extended Requirements you can think of:
·
Group Chats: As you are already aware of these group
chat concepts. The Messenger service that we are going to develop must support
this group chat where multiple people can talk to each other in a group.
·
Push notifications: Messenger must be capable of notifying the status changes to the users as
well as whenever there is any new message received when the user is offline.
Capacity Estimation and Constraints
v Let’s assume
that we have 100 million daily active users and on average each text-based instant
messaging services support the persistent storage of chat history real-time
chat experience with minimum latency. Can endure lower accessibility in light
of a legitimate concern for consistency
v Let’s assume
that we have 100 million daily active users and on average each user sends 20
messages daily; this gives us 2 billion messages per day.
v Storage
Estimation: Here, let’s say that on average a message is 100 bytes, store all
the messages in the database for a
single day, we are going to require1TB
of storage2 billion messages * 100 bytes => 20GB/day.
Note: Theabove calculation doesn’t take data compression and replication into consideration.
Read related Post How to create Facebook Page
Detailed Component Design
Here, our
predominant goal is that we should attempt to develop a straightforward
solution first where everything runs on one server. At a high level, our framework
needs to deal with the accompanying use cases:
1. The User should
receive the incoming messages when they
are online and users can send messages and our application will deliver the outgoing
messages.
2. Storing and
retrieval of the user messages/Images from the database.
3. Keeping track of
the online and offline status of the users at every point of time and then
accordingly, notify these status changes to all the relevant users.
How would we efficiently send/receive messages?
To send
messages, a client needs to communicate with the Node/Chat server and publish
messages and deliver it to different clients. To receive a message from the
server, the client has two choices
1. Push model: If
we go with our Push Model, where all the active users keep a connection open
with the server, then This way, the server doesn't have to monitor the pending
messages, and here minimum latency we will have because the messages are
conveyed in a flash on the opened connection.
.
How can the Node/Chat server efficiently keep track of all
the opened connection for redirecting messages to the users?
The server
in this case have to maintain a hash table/ HashMap and whenever the server gets any message from a
user, then it looks up that specific user in the collection where we have already stored the active user lists to
find the connection object and sends the message
How can the clients efficiently retrieve data from the
server?
Ø We need to keep
track of user’s online/offline status and Since we are maintaining a connection
object on the server for all active users, we can easily figure out the user’s
current status from this.
Ø To assume with 200M
active users at any time, it is obvious that if we have to broadcast each
status change to all the relevant active users, then is going to consume a lot
of resources. So, here we can think of a better optimization process around this
problem statement. At any point of time if a user opens his/her messenger app, then
the application should pull the current status of all of his/her
friends/contacts from the friend list.
How can the client maintain an open connection with the
server?
v Clients will be capable
of pulling the status from the server about those clients that are being appeared
on the user’s viewport. This should not be a regular activity, as the server is
communicating or publishing User’s online status to other users in the friendliest.
v Whenever the user
initiated a new chat with any another
user, at this time we can be able to pull the status of that user. So, here, this
requires a fewer number of message/conversations in the viewport. Server should
notify all the relevant users whenever a status change happens and then it sends
a message to another user that went offline.
v we can send a failure to the sender and update the status on the client user comes online, the server can always publish/broadcast that status with few seconds delay just to confirm that user will not be offline immediately.
Design Summary:
Ø Clients will just
initiate an open connection to the Node server i.e. nothing but our chat server
to send a message; the server will then forward the message to the other end user.
The users whoever has logged into the application(Active Users), they will keep
the client connection open with the Node/chat
server to receive messages.
Ø If any new
message arrives, then immediatel your node/chat server will push it to the client
I mean the receiving user on the long poll request. Messages can be stored in
HBase/Cassandra which supports quick small updates, and range-based searches. The
Chat/Node servers what they do is they will broadcast/publish the status change
of a user either online/offline to other relevant users. Then in the Client
side, user can see other online users
from his/her friend lists, and this is possible because Clientpulls the status
updates ofthe other active users (those
who are visible in the client’s viewport on a less frequent basis).
Ø There is a need of a load balancer in front of our Node/chat servers; This can map each“User_ID” to a server that holds the connection for that specific user and then direct the request to that server.
Fault tolerance and Replication
- Now think about the scenario where our chat server or
Node server fails? In our application, Our chat/node servers are going to hold the connections with the clients(User side). If any node goes down from the available servers, then here problem may arise. Whether we should devise a mechanism to transfer those connections to some other server?
- Here the question can come into your mind that whether we should store multiple copies of user messages or not? Ideally speaking, we cannot have only one copy of the user’s data, because have to store multiple copies of the data on different servers or need to adopt theReed-Solomon encoding like techniques to distribute and replicate it.
No comments
Note: Only a member of this blog may post a comment.