System requirements

Functional:

• Indicate online when the user starts the application
• Indicate offline when the user closes the application
• Indicate idle when the service does not receive activity after 5 minutes
• Indicate offline after 15 minutes
• Users can see other people's status

Non-Functional:

• Able to support multiple users (millions)
• Must be highly available to ensure that the updates are made all the time
• if a user changes their status at a certain time, the system need not reflect it immediately

Capacity estimation

Traffic Estimations:

• 1 million daily active users,
• each user requests for 50 other user status information daily

Data:

• UserID (8 bytes)
• Indication(4 bytes) 0 = offline, 1 = online, 2 = idle
• last_activity (4 bytes) : the time of the last activity
• Currently_viewing (array) : 1MB

Storage estimations

• 5 million total users
• 5,000,000 * (8+4+4 + 1MB) = 5000 GB

API design

establish_socket(userID): sent from client to server, creates a webSocket between the client and the backend server

send_heartbeat(userID): This will be sent from the server to the client to check whether the WebSocket is still established, this function will also check the last activity that was sent from the user

send_heartbeat(userID): This will be sent from the client to the server, the time will then be taken by the server

view_status(userID) sent from client to server and returns the status of the requested user

update_status(userID), sends the updated status of a user to those currently viewing the user

Database design

We can store our data in a documentDB, since we have an array, this makes our data unstructured. SQL would not be ideal in this case.

High-level design

Client that is connected to servers and then to a documentDB.

We should also have load balancers between client and servers and between servers and DBs.

Request flows

When the user opens up the application, a WebSocket is established between the client and the server. The server will then write in the database that the user is 'online'.

Users can call view_status to check the status of another user. the server will add your userID to the array of userIDs that are currently viewing the other person's status. When you leave, then the server will remove your name from the array.

Every 30 seconds, the server will send a heartbeat to users to check whether a WebSocket is still established. The client will send either 1 to indicate that the user is using the applciation or 0 to indicate that the user is not using it at the moment. If 1, the server will update the database to the time of last_activity. If no response, meaning that the websocket has been closed, then the user is offline.

If 0, then the server will check the database to see how long since the last activity. if has been 5 minutes since activity, the server will update the DB to indicate that the user if offline. if offline, then the server will simple update the DB to indicate that the person is offline. The DB will then retrieve an array of people currently viewing another user and send them the updated status through their websockets

Detailed component design

How do we handle hot users? meaning a lot of people are viewing their status. We could do so by using a cache, if we cache the top 20% of data per day, we would need 10GB of cache storage. We can also use the LRU algorithm for data eviction

How do we do data sharding? basically by userID

Assuming that a server can handle 100,000 connections, we need about 7-8 servers to handle the load, in addition, we need backup servers, this is in case some servers crash, or there is a period of heightened activity. We will have load balancers to split the load

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

We can improve this by sending the last active time of a user as well