System requirements

Functional:

• User Status management
• Real-time Status updates
• User Activity Tracking
• Status Notifications
• Status Search
• Integration with User Accounts

Non-Functional:

• Scalability
• Reliability
• Real-Time Performance
• Security
• Privacy
• Monitoring and Logging

Capacity estimation

• Average User Activity: 1 status update per minute.
• Peak Traffic: 5 times the average traffic during peak hours.
• Expected Concurrent Users: 10,000 users.
• Response Time: 100 ms for status updates.

Average TPS = (Average User Activity/ 60 seconds) * Expected Concurrent Users

Average TPS = 1/60 *10000 = 166,67 TPS

Peak TPS = 166.67 * 5 = 833,33 TPS

each instance can handle up to 200 TPS

Database requirements 1000 IOPS (Input/output operations per second)

Number of Presence Services = 833,33 / 200 == ca. 5 instances

Database IOPS Required = 833,33 * 1000 = 833330 IOPS

API design

• User Status Update
• Endpoint: /status/{userId}/update
• POST
• allows users to update their online status - request should include the User ID and the new status
• Get User Status
• Endpoint /status/{userId}
• GET
• gets the current status of the user
• Get Online Users
• Endpoint /status/online
• GET
• gets all current online users
• Subscribe to Status Updates

Database design

• The USER table stores user information such as user_id, name, and email.
• The STATUS table stores the user's status updates, including the status_id, user_id, status (online, idle, offline), and the timestamp of the update.
• The CONNECTION table establishes connections between users, allowing tracking of relationships between users.

Key considerations in the database design:

1. Indexes: Create indexes on frequently queried columns like user_id to improve query performance.
2. Normalization: Ensure data normalization to eliminate data redundancy and improve data integrity.
3. Data Consistency: Implement constraints and triggers to maintain data consistency, such as ensuring a user can only have one status update at a time.
4. Replication: Consider database replication for high availability and fault tolerance.
5. 
   

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...

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...

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...

Trade offs/Tech choices

1. Real-time Updates vs. System Load: Providing real-time updates for user statuses can lead to increased system load due to a higher frequency of data updates. Balancing the need for real-time updates with the system's capacity to handle the load is crucial.
2. Data Consistency vs. Performance: Ensuring data consistency across distributed systems may impact performance. Trade-offs between strong consistency guarantees and lower latency may need to be made based on the requirements of the system.
3. Scalability vs. Complexity: Implementing a highly scalable system may introduce complexity in managing distributed components, data consistency, and fault tolerance. It's essential to strike a balance between scalability and the complexity of the system.
4. Storage Requirements vs. Cost: Storing real-time status updates and user data can lead to increased storage requirements. Balancing the need for historical data with the cost of storage can be a trade-off to consider.
5. Latency vs. Data Freshness: Minimizing latency for status updates may impact the freshness of the data. Trade-offs between low latency and near real-time data freshness may need to be evaluated based on user expectations.
6. Security vs. Performance: Implementing robust security measures, such as encryption and authentication, may introduce additional processing overhead. Balancing security requirements with system performance is essential to maintain a secure yet responsive service.
7. 
   

Failure scenarios/bottlenecks

1. High Traffic Volume:

• Bottleneck: The system may experience bottlenecks during peak traffic hours if the services cannot handle the increased load efficiently.
• Failure Scenario: If the system cannot scale horizontally to accommodate the high traffic volume, users may experience delays in status updates or system unresponsiveness
• Database Outages:
• Bottleneck: Database performance or availability issues can become a bottleneck for the entire system.
• Failure Scenario: If the database experiences outages or high latency, user status updates may be delayed or lost, impacting the real-time nature of the service.

1. Network Latency:

• Bottleneck: High network latency can slow down communication between service components.
• Failure Scenario: In scenarios where network latency is high, real-time status updates may be delayed, affecting the responsiveness of the service.

1. Service Failures:

• Bottleneck: Single points of failure within the system architecture can lead to service disruptions.
• Failure Scenario: If a critical service (e.g., Presence Service) fails due to hardware or software issues, users may not receive real-time status updates or notifications.

1. Security Vulnerabilities:

• Bottleneck: Inadequate security measures can become a bottleneck for the system's overall stability.
• Failure Scenario: If the service is vulnerable to security threats, such as unauthorized access or data breaches, user data integrity and privacy may be compromised, leading to service disruptions.

1. Inefficient Data Storage:

• Bottleneck: Inefficient data storage mechanisms can impact the performance of data retrieval and updates.
• Failure Scenario: If the database design is not optimized or lacks proper indexing, queries for user status updates may be slow, affecting the real-time nature of the service.

Future improvements

additionally there could be a better authentication inplace, also we could add an encryption for the databases so we ensure privacy for our customers and their data

to reduce network latency we could use rate limiters

To mitigate database outages we could utilize database sharding or creating replicas of databases, so that when database goes off we have the other databases available

Use health check services like prometheus and graphana to check the health of all services and whether they are up and running and everything is working great

add logging to be able to track potential errors, when they occur and mitigate potential future failures