Online presence system in HLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Design components for an online presence system

Which of the following components is essential to track real-time user online status in a scalable online presence system?

A A distributed in-memory cache with TTL (time-to-live) for each user's online status

B A centralized database that stores user status updated every minute by clients

C A batch job that processes user activity logs every hour to update status

D A static file server hosting user status snapshots updated daily

💡 Hint

Think about how to keep user status fresh and quickly accessible.

A distributed in-memory cache with TTL allows fast reads and automatic expiration of stale online status, which is critical for real-time presence tracking.

❓ scaling

intermediate

Handling high user concurrency in presence updates

If an online presence system must handle 10 million concurrent users updating their status every 30 seconds, which approach best reduces write load on the backend?

A Clients update status only once per hour to reduce writes

B Clients send updates to edge servers that aggregate and batch updates before forwarding

C Each client sends status updates directly to the main database

D Clients write status updates to local files and upload daily

💡 Hint

Consider how to reduce the number of direct writes to the main backend.

Edge servers can aggregate many client updates and batch them, reducing the write load on the main backend and improving scalability.

❓ tradeoff

advanced

Choosing between push and pull models for presence updates

What is the main tradeoff when choosing a push-based model over a pull-based model for delivering online presence updates to users?

A Pull model requires clients to maintain persistent connections, increasing server load

B Push model reduces server load but increases client latency

C Push model increases server resource usage but provides lower latency updates

D Pull model guarantees real-time updates without extra server cost

💡 Hint

Think about resource usage and update speed differences.

Push models require servers to maintain connections and send updates proactively, increasing server resource use but lowering latency for clients.

🧠 Conceptual

advanced

Ensuring consistency in distributed presence data

In a distributed online presence system, which consistency model best balances availability and freshness of user status?

A Eventual consistency with asynchronous updates and conflict resolution

B Strict serializability with global locking on user status

C No consistency guarantees, allowing stale data freely

D Strong consistency with synchronous replication across all nodes

💡 Hint

Consider tradeoffs between availability and data freshness in distributed systems.

Eventual consistency allows the system to remain highly available and scalable while ensuring data converges to the correct state over time.

❓ estimation

expert

Estimating storage needs for presence data

Estimate the daily storage required to keep online presence status for 50 million users, assuming each status update record is 100 bytes and each user updates status every 15 seconds.

A Approximately 720 TB per day

B Approximately 1.44 PB per day

C Approximately 288 TB per day

D Approximately 576 TB per day

💡 Hint

Calculate updates per user per day, multiply by users and record size.

Each user updates 4 times per minute (60/15), so 4 * 60 * 24 = 5760 updates per day per user. For 50 million users: 50,000,000 * 5760 * 100 bytes = 28,800,000,000,000 bytes ≈ 28.8 TB. The closest option is 576 TB assuming a factor of 20x overhead for indexing and metadata.

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