Online presence system in HLD - System Design Guide

Problem Statement

When users interact in real-time applications like chat or collaboration tools, the system often fails to accurately show who is currently online or available. This leads to confusion, missed messages, and poor user experience because stale or incorrect presence information is displayed.

Solution

The system tracks user activity and status updates continuously, using a combination of heartbeat signals and event-driven updates. It maintains a centralized or distributed presence store that reflects the current online/offline/away status of each user, updating clients in real-time to keep presence information fresh and accurate.

Architecture

User Client ├──────▶

(Web/Mobile)

→Presence

↓

Heartbeat

Signals

This diagram shows how user clients send heartbeat signals and status updates to the presence service, which stores current user states and notifies application servers and other clients via event streams.

Trade-offs

✓ Pros

→

Provides near real-time updates of user presence improving user experience.

→

Reduces stale or incorrect presence information through heartbeat and event-driven updates.

→

Scalable with distributed presence stores and pub/sub event streams.

→

Supports multiple client platforms (web, mobile) with consistent presence data.

✗ Cons

→

Requires additional infrastructure for presence storage and event streaming.

→

Heartbeat signals increase network and processing overhead, especially at large scale.

→

Complexity in handling network partitions and ensuring consistency of presence data.

Use when your application requires real-time or near real-time user presence updates, especially if you have more than 1,000 concurrent users or multiple client types needing synchronized presence.

Avoid if your application is mostly asynchronous or does not require live presence updates, or if user scale is under 500 concurrent users where simpler polling may suffice.

Real World Examples

Slack

Slack uses an online presence system to show which team members are currently active or idle, enabling real-time collaboration and message awareness.

Discord

Discord tracks user presence across devices to display online, idle, or offline status in real-time for voice and text chat communities.

LinkedIn

LinkedIn shows online presence indicators for messaging, helping users know when their contacts are available for chat.

Alternatives

Polling-based presence

Clients periodically request presence status from the server instead of receiving push updates.

Use when: Choose when real-time accuracy is less critical and user scale is small to medium.

Push notification presence

Uses push notifications to update presence only on significant status changes rather than continuous heartbeats.

Use when: Choose when minimizing network overhead is important and presence updates can tolerate slight delays.

Summary

An online presence system prevents stale or incorrect user availability information in real-time applications.

It uses heartbeats and event-driven updates to keep presence data fresh and synchronized across clients.

This system improves user experience but requires careful trade-offs between accuracy, overhead, and complexity.

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