System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

1. The user status should be displayed on their profile.
2. When a user goes from offline to online, the user's friends on the platform should get a notification.
3. When a user logs in, their status should be set to online.
4. If an online user has not attempted any activity on the platform for 10 minutes, their status should be updated to idle.
5. If an idle user has not attempted any activity on the platform for 10 minutes, their status should be updated to offline.
6. If an idle or offline user attempts any activity on the platform, their status should be updated to online.
7. Users can manually set their status to "Away" or "Online."
8. If a user logs out, their status should be set to online.
9. A user can set the visibility of their status.
10. The status data should be queriable for 3 years.

Non-Functional:

List non-functional requirements for the system...

1. The system should handle a large number of concurrent users.
2. The system should be highly available.
3. The system should provide real-time updates with minimal delay.
4. The system should recover gracefully from failures, employing retries or failover strategies.
5. The system should ensure data privacy and security, adhering to regulations and best practices for user data protection.
6. Ensure that the user status data is consistent across all components.
7. There should be logging and monitoring services for the system.

Capacity estimation

Estimate the scale of the system you are going to design...

Let's make the following assumption:

1. There are 10 million Daily Active Users.
2. 10% of DAU, which means 1 million, is typically active simultaneously.
3. Assume each updates their status every minute, which is 1 million updates per minute.
4. Assuming that each of these online active users may get status updates for some changes of their friends, let's assume they get, on average, three notifications per user per hour. That means we get 10,000,000 * 3 / 60 = 50000 notifications per minute.
5. Assume our data retention policy is three years, and we store an update in 30 bytes. That means we need to store 1,000,000 * 60 * 24 * 365 = 1,000,000 * 500,000 = 500, 000, 000, 000 updates, which is 15, 000, 000, 000, 000 bytes or 15 terabytes.

API design

Define what APIs are expected from the system...

GET /userStatus(userId, queryingUserId)

PUT /userStatus(userId, status, timestamp)

Enum Status:

ONLINE, IDLE, AWAY, OFFLINE

PUT /statusVisibility(userId, visibilitySettings)

enum VisibilitySettings:

PUBLIC, FRIENDS_ONLY, PRIVATE

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

User Table (SQL)

userId, Int (Primary Key)

Status, String

User Activities (Redis Set)

userId, Int (foreign key)

last_active_at, timestamp

A redis set is used to keep the last timestamp to support both high read and high write volume.

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

There are about 5 conceptual components in the system:

Subscriber: This component should be in the client and is subscribed to real-time service, listening to the status events from interested topics (friends). Its connection to realtime service should be a SSE connection. The subscriber should also talk to presence service to get the status of a user.

Publisher: This component should also be in the client, and events such as heartbeat and status updates should be published in the real-time service. Its connection to real-time service should be a SSE connection.

Realtime Service: This is the service in charge of listening to publisher and broatcasting events to subscribers.

Presence Service: This is the service that should be talking to subscriber and directly returning them the initial presence data when a user first start to subscribe to the status of a friend.

Presence database: This is the database that preserves the status of users.

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Subscribe Flow:

When a user first start subscribing to a friend. The following steps happen:

1. Subscriber will query Presence Service to get the status of the friend.
2. The Presence Service query Presence Database to fetch the current status of a friend, and sends it back to the subscriber.
3. The subscriber establishes an SSE connection with the realtime service for future updates.

When a user updates their status, the following steps happen:

1. The publisher, periodically or triggered by a user update, sends an event to the real-time service containing its current status.
2. The real-time service updates the presence service about this status.
3. The presence service queries the presence database and detects if there is a status change.
4. If there is a status change, the presence service notifies the realtime service in its response.
5. The realtime service will broadcast the update to all the interested subscribers.

When a user status timeout, the following steps should happen:

1. Inside presence service, there should be a process that runs periodically to check if any database record is timing out.
2. If some of the users has their status timed out, the presence service updates the database, and notifies realtime service about this through API call.
3. Realtime service will then broadcast the change to all subscribers.

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

The Presence Service should be used to detect if a client is timeout.

Each time when the Presence Service receives a timestamp about a client, it sets a delayed trigger for the client or reset it if it is already exists. When a delayed trigger is triggered, it will query Presence Database to make sure that the client is indeed timing out. If that's correct, it sends a request to realtime service and have it broadcast the fact that the client is offline.

The realtime service consists of a number of components, a dispatcher, a gateway server, and each gateway server should have an associated subscription store, and there should be a shared endpoint store.

When subscribing to a topic, the subscriber establish a SSE connection with a gateway server. The gateway server will then stores the subscription information into the local memory subscription store, and if this is the first subscriber in this server for the same topic, it will store this into the shared endpoint store.

When a publisher publishes a topic, the publisher first publishes the event to a dispatcher. The dispatcher will query the shared endpoint store to find all gateway servers that's subscribed to this topic, and dispatches the events to all of them. The gateway server will then forwards the event to the subscribers based on its local subscription storage.

Trade offs/Tech choices

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

In the presence database, the last active timestamp is stored in a key-value pair storage redis Set instead of an ACID or other NoSQL database such as Apache Cassandra, as redis supports fast access, very suitable for this use case. This use case also does not require the relational information, ACID… that would require a more complicated implementation.

Failure scenarios/bottlenecks

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

One Failure scenario would be a jittery connection. To handle this, the timeout of a client in the Presence Service should be set to a reasonably long time.

Both presence service and realtime service should have duplicate. If a realtime server is down, both publisher and subscriber connected to it should retry connection.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

More duplications, or multiregional deployment should be introduced as more users are joining.