High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

User connects to load balancer which then connects to API gateway and to Control plan server APIs. The control plane server apis talks to Group Management Service and User Management Service. The group management service talks to No SQL Db which maintains the Group information about who is the group and members and other metadata info.

The User management service similarly service talks to the No SQL Db which maintains the information about the users and their metadata.

The other main service is the message service which is responsible for storing messages sent to Group or User in the No SQL Db and can be used to retrieve the message history. Using this you can retrieve the messages that were sent.

The Message service also talks to the redis cluster which maintains the live messages that are being sent and stores them in the message No SQL Dbs.

The user also opens a connection to Real Time server which then uses SSE events to push the messages back to the user.

Here is the flow, when the user logs in, app connects to real time server create a channel in the Redis Cluster which allows anyone to post the message to it i.e. other users can post the message. If the user stop sending the heat beat, the channel is closed.

When a user post a message, the control plane server forwards the message to the message service, which then store the messgae in the No SQL DB, and also check if a recipient channel is open in the redis cluster. If channel is open, it means the user is online and you can send the message which will allow redis to generate event and send message back to the user.

If channel doesn't exists, then message server simply sends it to notification service which will then send a notification to the user using push system (iOS/Android). So when the user login in, the messages are then directly retrieved from the message service using control plane.

API Gateway handles any burst and abuse of control plane apis i.e. throttling per user etc. It's also responsible for authenticating the users.

For messages sent to the Group, similar path is followed, the control plan API receives the message, that message is then forwarded to the message service along with information about the group itself from the group management service. The messages are the forwarded to Group Fan Out service which effectively figures out which users the messages needs to be delivered to and send sends the message to the all user channels. The message is also stored in the message No SQL DB.

When the real time servers forwards the message to the app, the app can also call back the Control Plane API to mark that particular message as received. This allows for user to retrieve only messages which were not received before when the app initially boot ups. This also takes care of the issue when app reconnects.

If the app loses connectivity, it simply reestablishes the connection and calls control plane api to recieve all unreceived messages. The key point to note is that each message is identified with globally unique messageId (could be generated using UUID), which allows for de-duplication etc.. i.e. even if app accidentally receives same messages from control plane and real time plane, it know it;s same message and can easily manage it. All messages are timestamped as well to make sure message are displayed in order.

Redis Channels are managed by the real time servers. If the user loses the connection, the channels are closed. Every message is stored in the message No SQL db, so messages are never lost. If the connection is lost, the message is never delivered and when app reconnect, it will simply open the channel again. App will get the message through the control plane.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10