Design An Online Presence Indicator Service - System Design

System requirements

Functional:

Track user connection status (online, idle, offline) across the platform
Update user status in real-time based on activity or inactivity
Allow users to set their status manually (e.g., "appear offline" mode)
Notify interested parties when a user's status changes
Provide an API for other services to query a user's current status
Support status history retrieval (e.g., when a user was last online)
Handle user sessions across multiple devices (mobile, web, desktop)
Apply configurable timeouts for transitioning between states (e.g., from online to idle after 5 minutes of inactivity)

Non-Functional:

Here are the key non-functional requirements we should consider:

Scalability: The system should handle millions of users and their status updates efficiently.
- Horizontal scalability to accommodate user growth
- Ability to handle spikes in connection/disconnection events
Performance:
- Low latency for status updates (< 500ms)
- High throughput for status queries
- Efficient handling of presence broadcasts to relevant users
Reliability:
- High availability (99.99% uptime) as this is a core platform feature
- Fault tolerance to handle component failures
- Data consistency across distributed components
Real-time Requirements:
- Status changes should propagate to interested parties within 1-2 seconds
Consistency vs. Availability Trade-offs:
- May favor availability over strict consistency (eventual consistency model)
- Temporary inconsistencies in status display are acceptable
Security:
- Privacy controls for who can view a user's online status
- Protection against spoofing or status manipulation
Cost Efficiency:
- Optimize resource usage for a large-scale deployment
- Minimize bandwidth consumption for status broadcasts

Capacity estimation

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

1. User Status Management APIs

Copy
POST /api/v1/status

Purpose: Update a user's status (manually or automatically)
Request:

json
Copy
{
  "userId": "user123",
  "status": "online|idle|offline|invisible",
  "deviceId": "device456",
  "timestamp": 1649276349000
}

Response:

json
Copy
{
  "success": true,
  "userId": "user123",
  "statusUpdated": "online",
  "timestamp": 1649276350000
}
Copy
GET /api/v1/status/{userId}

Purpose: Retrieve current status of a user
Response:

json
Copy
{
  "userId": "user123",
  "status": "online",
  "lastActiveTimestamp": 1649276349000,
  "devices": [
    {
      "deviceId": "device456",
      "status": "online",
      "lastActiveTimestamp": 1649276349000
    }
  ]
}
Copy
GET /api/v1/status/batch

Purpose: Retrieve status for multiple users at once
Request:

json
Copy
{
  "userIds": ["user123", "user456", "user789"]
}

Response:

json
Copy
{
  "users": [
    {
      "userId": "user123",
      "status": "online",
      "lastActiveTimestamp": 1649276349000
    },
    {
      "userId": "user456",
      "status": "idle",
      "lastActiveTimestamp": 1649275349000
    },
    {
      "userId": "user789",
      "status": "offline",
      "lastActiveTimestamp": 1649176349000
    }
  ]
}

2. WebSocket API for Real-time Updates

Copy
WebSocket /api/v1/presence/connect

Purpose: Establish real-time connection for status updates
Connection Parameters:
- Authentication token
- Device identifier
Events:
- status_update: When status of a monitored user changes
- heartbeat: Periodic ping to maintain connection
- activity: Client sends activity signals to reset idle timer

3. Subscription Management API

Copy
POST /api/v1/subscriptions

Purpose: Subscribe to status updates for specific users
Request:

json
Copy
{
  "subscribeTo": ["user456", "user789"],
  "notificationMethod": "websocket|webhook"
}

Response:

json
Copy
{
  "success": true,
  "subscriptionId": "sub123",
  "subscribedTo": ["user456", "user789"]
}
Copy
DELETE /api/v1/subscriptions/{subscriptionId}

Purpose: Unsubscribe from status updates

4. Privacy Settings API

Copy
PUT /api/v1/privacy/status

Purpose: Configure who can see a user's status
Request:

json
Copy
{
  "visibility": "everyone|contacts|specific|none",
  "specificUsers": ["user123", "user456"],
  "excludedUsers": ["user789"]
}

Response:

json
Copy
{
  "success": true,
  "privacySettings": {
    "visibility": "specific",
    "specificUsers": ["user123", "user456"],
    "excludedUsers": ["user789"]
  }
}

5. Administrative API

Copy
PUT /api/v1/admin/config/timeouts

Purpose: Configure system timeout settings
Request:

json
Copy
{
  "idleTimeout": 300, // seconds
  "offlineTimeout": 1800, // seconds
  "heartbeatInterval": 30 // seconds
}

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

High-level design

Here's how this architecture works:

User Devices: End users connect from various devices (web, mobile, desktop).
Load Balancers: Distribute incoming connections and requests across multiple presence servers.
Presence Servers: Handle user connections, status updates, and status queries.
- Manage user sessions
- Process status changes
- Apply timeout rules for idle/offline transitions
Status Store: Distributed database that maintains the current status of all users.
- Fast read/write operations for status data
- Support for high availability and partitioning
Pub/Sub System: Messaging infrastructure to broadcast status changes.
- Provides real-time updates
- Decouples status change events from notification delivery
Notification Dispatcher: Delivers status change notifications to relevant users.
- Filters notifications based on privacy settings
- Optimizes notification delivery to minimize bandwidth

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

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

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