Design an Online Presence Indicator Service

A green dot next to a name, trivial to display, brutal to compute at scale. 10 million users online simultaneously, each sending a heartbeat every 30 seconds to prove "I'm still here." That is 330,000 writes per second just for keepalive signals. Now multiply: when one user goes offline, every friend watching their status needs to know within one second. The core challenge is not storing state. It is propagating state changes to hundreds of friends before they notice any delay.

Functional

Real-time presence tracking: Track each user as online, idle, or offline. A user connects and becomes online. After a period of inactivity they transition to idle. When they disconnect or miss heartbeats they transition to offline. The system maintains a state machine per user with well-defined transitions.

The heartbeat math drives every infrastructure decision. 10 million concurrent users each sending a heartbeat every 30 seconds means 330,000 writes per second just to maintain liveness. Each heartbeat is tiny, roughly 50 bytes (user ID, device ID, timestamp). But the volume is relentless and cannot be batched or deferred.

Traffic

500 million registered users, 100 million daily active, 10 million concurrent online at peak. Average friend count is 200.

Two communication patterns serve different needs. WebSocket carries the continuous heartbeat and push notification traffic. REST handles discrete queries and settings changes. Sending 330K heartbeats per second over HTTP would create 330K TCP handshakes per second, WebSocket amortizes the connection cost across thousands of heartbeats.

WebSocket Protocol

Client heartbeat (sent every 30 seconds): { "type": "heartbeat", "device_id": "d_abc123", "ts": 1709567890 }

Two storage tiers, each optimized for a different access pattern. Redis for live presence state, sub-millisecond reads at 330K writes per second, with automatic expiration handling offline detection. PostgreSQL for durable data, friend lists, user settings, and last-seen timestamps that must survive restarts.

Redis: Live Presence State

Each online user gets a hash in Redis:

Four services, one pub-sub backbone. The WebSocket Gateway holds 10 million persistent connections. The Presence Service manages state transitions and timeout detection. Redis stores live state and handles event distribution. The Friend Service resolves friend lists for fan-out targeting.

WebSocket Gateway: Accepts and maintains persistent client connections. Receives heartbeats and forwards them to the Presence Service. Subscribes to Redis Pub/Sub channels for friend status updates and pushes them to connected clients. Stateless except for the connection registry (which clients are connected to this gateway instance).

Two flows define this system. The heartbeat flow runs 330K times per second. A lightweight write path that must complete in under 1 millisecond. The status change fan-out flow runs 1,700 times per second, a complex read-and-distribute path that must complete in under one second including delivery to all affected friends.

Heartbeat Processing Flow

"How do you detect that a user went offline?" is the question that separates surface-level answers from deep understanding. Three mechanisms compete: heartbeat timeout, explicit disconnect, and TCP connection drop. The challenge is avoiding false transitions. A user on a flaky mobile network should not flicker between online and offline every 10 seconds.

Grace Period

When a heartbeat is missed (the timing wheel slot expires), the system does not immediately declare the user offline. Instead, a grace period of 10 seconds begins. If a heartbeat arrives during the grace period, the transition is cancelled and the user stays online. If no heartbeat arrives, the user transitions to offline.

Three cascading decisions shape this architecture: how to detect disconnects, how to distribute status changes, and how to assign users to gateway instances. Each decision constrains the options for the next.

Push via WebSocket vs. HTTP Polling

WebSocket provides sub-second status updates with one persistent connection per client. The alternative (HTTP polling every 5 seconds) adds 2 million requests per second (10M users / 5s interval) with guaranteed 0-5 second staleness. Polling is simpler (no persistent connections, standard HTTP load balancers) but cannot meet the one-second latency requirement. WebSocket wins for real-time but requires connection-aware load balancing and gateway-level state management.

Redis holds all live presence state. If it goes down, every user appears offline. A WebSocket gateway crash drops thousands of connections simultaneously. A login surge at 10 AM overwhelms the fan-out path. Each failure mode has a different blast radius and recovery pattern.

Redis Primary Failure

Redis Sentinel detects the failure and promotes a replica within 5-10 seconds. During failover, heartbeat writes fail and presence reads return empty. All users appear offline to their friends. Recovery: clients continue sending heartbeats, which rebuild state in the new primary. Within 30 seconds (one heartbeat interval), all online users have re-registered. The 5-10 second outage causes a brief universal "everyone offline" flicker.

Four extensions beyond the core system, each building on the foundation without requiring architectural changes.

Custom status messages: "In a meeting," "On vacation," "Gaming." Stored as a string field in the Redis presence hash alongside the status enum. Fan-out follows the same path as status changes. The main complexity is UI, custom statuses need expiration timers ("Do Not Disturb until 5 PM") and character limits.

Richer activity states: Instead of the core design's single idle flag (no input for five minutes), report granular client-side activity signals. The client includes mouse movement, keyboard input, or scroll events in the heartbeat payload. This enables finer-grained status: "active" (typing), "online" (app open, not interacting), "idle" (app backgrounded). The trade-off is increased heartbeat payload size and client-side tracking complexity.