WhatsApp Design Part 3

If you haven’t read earlier parts, encourage you to start from here.

This article will be focused on the use-case when a user sends a message. Following services will come into play session service, message service, and parser. We will discuss the roles and responsibilities of each service first then in the end will put them all together to create a workflow.

1. Connection Service

This service is responsible for handling active connections between Gateway and users. It maintains information on which gateway is connected to which user. Connection service will maintain the buffer for newly created connections and push the data in DB in blocks to reduce DB calls for storing the data. The possible APIs:

POST Object connectionSetup(api_key, user_id, user_ip, port)

GET Gateway_id getGatewayId(api_key, user_id) // to find the gateway for given user_id

2. Message Service

This service handles the delivery of one-to-one messages from the user. Message service will store the recent data about connections and messages in its local cache.

POST message_id sendMessage(api_key, sender_id, receiver_id, message, type_message)

3. Parser Service

• In WhatsApp, all the conversations are encrypted. Can have a common parser service for handling the encryption and decryption of messages instead of each service separately handling it separately. Hence, this service is responsible for handling encrypted messages to and fro from the user.
• This can be a stateless service.

FLOW: Let’s check how the data will flow for connecting a user to a WhatsApp server and sending messages.

1. As soon as User_B comes online, it will send the request to the gateway for setting up the connection. The gateway sends the request to the connection service, which will set up the session and stores all the related data in DB, and send the session object to the gateway.
2. Gateway once the connection is done, send the ACK to the user.
3. Now, user_b wants to send a message to user_c.
4. Gateway finds the message service instance and sends the message to the message service. Once, message service receives the send message request it will ask the connection service for the gateway where user_c is connected to.
5. Connection service sends the response i.e. gateway, active/inactive connection. On receiving the response message service, if the connection is active, will send the message to the responsible gateway. If the connection is inactive, it will create the event in Queue. (Will discuss later who will handle these inactive users message from the queue.)

Important Points

Message service and Connection service will log events in the queue, that will be subscribed by various services for handling use cases such as status/logs metrics/inactive users messages, etc.

Single ✅ for the message — when message service receives the message and sends the ACK to gateway

double tick ✅ ✅ for the message — when a message is sent to the required user. (When user_c receives the message, then ACK is sent to the message service, which will send the ACK to user_b via the gateway)

Read ✅ for the message — when the user opens the message, the front-end will send the ACK to the message service, which will send the ACK to user_b via the gateway)

For Queue i.e. message passing , can use kafka queue.