Functional & Non-Functional Requirements

The Online Presence Indicator Service needs to accurately reflect the real-time status of users on the platform. It should categorize users into three distinct states: online, idle, and offline. Users are considered online when they are actively engaging with the platform, idle when they're inactive for a certain period but still logged in, and offline when they have logged out.

Scalability is crucial since a large number of users can log in simultaneously, particularly during peak hours. The service should also offer low-latency updates, pushing real-time status changes to the front end while minimizing the load on the database.

Capacity Estimation

To estimate the resource needs, we can assume that the platform will have around 1 million active users. Each user interaction could potentially generate numerous status updates. Assuming that 80% of users are active at any time and a 20-second activity window for the idle status, we can calculate the load on the system.

Using caching for the online presence information can further reduce database reads. A load balancer will distribute incoming requests among multiple instances of the service, helping maintain performance under high load. The initial setup might require about 3-5 microservices, including a user status service, a caching layer, and a real-time update service.

API Design

The API should provide endpoints for getting user status and updating their presence. Example endpoints include:

• GET /users/{userId}/status - Fetches the current online status of a user.
• POST /users/{userId}/status - Updates the user's presence, taking JSON payload for the new status.
• GET /statuses - Retrieves a list of statuses for batch processing.

This API must be designed to handle high traffic and return responses quickly, ideally within 100-200ms.

Database Design

The database should be designed to store user statuses efficiently. A simple relational schema can include:

• Users: Stores user details and primary identifiers.
• PresenceStatus: Holds the current status, user ID, and timestamps of last activity.

Using a NoSQL database could also be beneficial for scalability, allowing for quick reads and writes, especially with frequent status updates. Incorporating a caching solution like Redis can cache these status updates temporarily to alleviate load on the database during peaks.

High Level Design

The high-level architecture of the Online Presence Indicator Service consists of several components:

• Client Side: The front end that interacts with users and displays their statuses.
• Load Balancer: Distributes incoming requests to multiple server instances to ensure availability.
• Presence Service: Handles logic to determine and update user statuses.
• Database: Stores user and status data.
• Cache: Utilizes Redis or similar for fast retrieval of frequently access statuses.
• Notifications Queue: Sends status updates to decrease direct load on the service.

Request Flows

The request flow begins when the user performs an action, such as clicking or typing.

The client sends an update to the Presence Service via the API. If the user is idle, the service updates the status to 'idle' and saves it in the database. The update is then sent to the cache to ensure it can quickly retrieve the current status if needed. Users connected via websockets will receive a push notification of the updated status.

Detailed Component Design

The main components of the Online Presence Indicator Service include:

• Client/API Layer: This handles interactions with the user and updates status.
• Load Balancer: To evenly distribute requests and maintain service quality.
• Microservices: They process presence updates and retrieve user statuses.
• Database: Where user status information is permanently saved.
• Cache: Speeds up data retrieval for frequent status checks.

Trade-offs & Tech Choices

One major trade-off is between consistency and availability. If the system uses strong consistency (i.e., every user status is updated immediately across all services), it may experience increased latency during high traffic.

Alternatively, opting for eventual consistency through caches and background processes could improve response times but might result in users seeing stale data temporarily. This hinges on the application's tolerance for slight inconsistencies.

Failure Scenarios & Bottlenecks

Potential failure scenarios include:

• Service Outages: If the presence service goes down, users might not be able to update their statuses. A fallback mechanism could be to display the last known status.
• Database Failures: In the event of database downtime, cached information can prevent loss of current status info for a short while. However, a persistent storage plan is necessary.

A monitoring system to alert engineers of service degradation can help in mitigating downtime.

Future Improvements

Future enhancements may include:

• Status History Tracking: Keeping a log of status changes to allow users to see their activity over time could be a valuable feature.
• Machine Learning: Incorporating predictions of user presence based on historical data could improve the service's responsiveness.
• Mobile Support: Dedicated services that efficiently handle online status on mobile platforms can enhance user experience further.

High Level Architecture Diagram

Database ER Diagram

Request Flow Sequence Diagram