Online presence system in HLD - System Design Exercise

Design: Online Presence System

Design covers real-time presence tracking, status updates, and querying presence. Does not cover user authentication system, messaging, or notification delivery.

Functional Requirements

FR1: Track and display users' online/offline status in real-time

FR2: Support up to 100,000 concurrent users

FR3: Allow users to see the presence status of their contacts/friends

FR4: Update presence status within 2 seconds of change

FR5: Provide an API for clients to query presence status

FR6: Handle user login, logout, and idle states

FR7: Ensure data consistency and availability

Non-Functional Requirements

NFR1: System must have 99.9% uptime

NFR2: API response latency p99 under 200ms

NFR3: Scale to 100,000 concurrent connections

NFR4: Support mobile and web clients

NFR5: Data retention for presence status is 24 hours

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Presence status store (in-memory cache and persistent storage)

Real-time communication layer (WebSocket or similar)

API gateway for client requests

User session manager

Message broker for event propagation

Database for storing presence history

Design Patterns

Publish-Subscribe for real-time updates

Cache aside pattern for presence data

Heartbeat mechanism to detect client disconnects

Sharding to scale presence data storage

Event sourcing for presence changes

Reference Architecture

Client Devices (Web/Mobile)
       |
       | WebSocket / API Requests
       v
  +-------------------+
  |   API Gateway     |
  +-------------------+
       |
       | REST API / WS
       v
  +-------------------+       +-------------------+
  | Presence Service   |<----->| Message Broker    |
  +-------------------+       +-------------------+
       |
       | Cache (Redis) for fast presence data
       v
  +-------------------+
  | Persistent Store  |
  | (NoSQL DB)       |
  +-------------------+

Components

API Gateway

Nginx / Envoy

Handles client connections, routes API and WebSocket requests

Presence Service

Node.js / Go microservice

Manages user presence state, updates cache and database, publishes events

Message Broker

Apache Kafka / Redis PubSub

Distributes presence change events to interested services and clients

Cache

Redis

Stores current presence status for fast read/write access

Persistent Store

Cassandra / DynamoDB

Stores presence history and durable data

Client Devices

Web browsers, Mobile apps

Send presence updates and receive real-time presence info

Request Flow

1. User logs in from client device and establishes WebSocket connection via API Gateway.

2. Presence Service registers the user as online, updates Redis cache and persistent store.

3. Presence Service publishes 'user online' event to Message Broker.

4. Subscribed clients receive presence update events via WebSocket.

5. When user goes idle or offline, client sends update; Presence Service updates cache and DB, publishes event.

6. Clients query presence status via API Gateway; Presence Service reads from Redis cache for low latency.

7. Heartbeat messages from clients help Presence Service detect disconnects and update status accordingly.

Database Schema

Entities: - UserPresence(user_id PK, status ENUM('online', 'offline', 'idle', 'busy'), last_updated TIMESTAMP) - PresenceHistory(id PK, user_id FK, status ENUM('online', 'offline', 'idle', 'busy'), timestamp TIMESTAMP) Relationships: - UserPresence stores current status per user - PresenceHistory stores time-series records of status changes - user_id links presence data to user identity

Scaling Discussion

Bottlenecks

API Gateway handling large number of concurrent WebSocket connections

Redis cache memory limits for storing presence of all users

Message Broker throughput for event distribution

Database write throughput for presence history

Detecting client disconnects accurately at scale

Solutions

Use multiple API Gateway instances with load balancer and sticky sessions for WebSocket connections

Shard Redis cache by user ID or region to distribute memory load

Partition Message Broker topics and use consumer groups for parallel processing

Use a scalable NoSQL database with write-optimized design for presence history

Implement heartbeat and timeout mechanisms with distributed coordination to detect disconnects

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Clarify real-time requirements and presence states

Explain choice of technologies for low latency and scalability

Describe how cache and persistent storage complement each other

Discuss how message broker enables event-driven updates

Address handling of client disconnects and stale data

Outline scaling strategies and bottleneck mitigation

Practice

1. What is the primary purpose of an online presence system in a chat application?

easy

A. To track if users are currently online or offline

B. To store chat message history permanently

C. To encrypt messages between users

D. To manage user account passwords

Solution

1. Step 1: Understand the role of presence system

   An online presence system tracks user activity to know if they are online or offline.

2. Step 2: Differentiate from other chat features

   Message storage, encryption, and password management are separate features not handled by presence systems.

3. Final Answer:

   To track if users are currently online or offline -> Option A

4. Quick Check:

   Presence system = user online status [OK]

Hint: Presence means tracking user online/offline status [OK]

Common Mistakes:

• Confusing presence with message storage
• Thinking presence handles security features
• Mixing presence with account management

2. Which event is NOT typically used in an online presence system to track user status?

easy

A. message_send

B. connect

C. disconnect

D. heartbeat

Solution

1. Step 1: Identify presence tracking events

   Presence systems use connect, heartbeat, and disconnect to track user activity.

2. Step 2: Recognize unrelated events

   message_send relates to sending chat messages, not presence tracking.

3. Final Answer:

   message_send -> Option A

4. Quick Check:

   Presence events exclude message sending [OK]

Hint: Presence tracks connection, not message sending [OK]

Common Mistakes:

• Assuming message events track presence
• Confusing heartbeat with message_send
• Ignoring disconnect event importance

3. Given this simplified presence update code snippet, what will be the user's status after 10 seconds?

user_last_seen = 0
current_time = 10
heartbeat_interval = 5
if current_time - user_last_seen <= heartbeat_interval:
    status = 'online'
else:
    status = 'offline'

medium

A. Error due to comparison

B. "online"

C. "offline"

D. "unknown"

Solution

1. Step 1: Calculate time difference

   current_time - user_last_seen = 10 - 0 = 10 seconds.

2. Step 2: Compare with heartbeat interval

   10 <= 5 is false, so status is set to 'offline'.

3. Final Answer:

   "offline" -> Option C

4. Quick Check:

   Time diff > heartbeat means offline [OK]

Hint: Compare last seen time difference with heartbeat [OK]

Common Mistakes:

• Mixing up less than and greater than
• Forgetting to subtract last seen time
• Assuming status is always online

4. Identify the bug in this presence update logic:

def update_status(last_seen, current_time, heartbeat=10):
    if current_time - last_seen > heartbeat:
        return 'online'
    else:
        return 'offline'

medium

A. Function should return a boolean, not string

B. The comparison sign should be reversed

C. Heartbeat value should be negative

D. No bug, logic is correct

Solution

1. Step 1: Analyze the condition meaning

   If time difference is greater than heartbeat, user should be offline, not online.

2. Step 2: Correct the comparison

   The condition should return 'offline' when difference > heartbeat, so the comparison sign must be reversed.

3. Final Answer:

   The comparison sign should be reversed -> Option B

4. Quick Check:

   Time diff > heartbeat means offline [OK]

Hint: Online if time diff ≤ heartbeat, else offline [OK]

Common Mistakes:

• Returning online when user is inactive
• Misunderstanding heartbeat meaning
• Ignoring return type correctness

5. You need to design an online presence system for a messaging app with millions of users. Which approach best ensures scalability and real-time accuracy?

hard

A. Store presence data in user profile tables updated once per day

B. Store user status in a centralized database and query it on every client request

C. Send presence updates only when users log in or log out, ignoring heartbeats

D. Use distributed in-memory cache with TTL and heartbeat updates from clients

Solution

1. Step 1: Evaluate centralized database approach

   Querying a centralized DB for every request causes high latency and bottlenecks at scale.

2. Step 2: Consider distributed cache with TTL and heartbeats

   This approach keeps presence data fresh, reduces DB load, and supports real-time updates efficiently.

3. Step 3: Analyze other options

   Ignoring heartbeats or updating once per day leads to stale presence info, unsuitable for real-time apps.

4. Final Answer:

   Use distributed in-memory cache with TTL and heartbeat updates from clients -> Option D

5. Quick Check:

   Distributed cache + heartbeat = scalable real-time presence [OK]

Hint: Use cache with TTL and heartbeats for scalable presence [OK]

Common Mistakes:

• Relying on centralized DB for real-time presence
• Ignoring heartbeat updates causing stale data
• Updating presence too infrequently