Design a User Presence System

1. Heartbeat Management and Time to Live Expiration

The core presence loop processes client heartbeats, updates in memory key state, and infers disconnection through time to live expiration rather than relying on explicit disconnect frames.

Active clients transmit lightweight heartbeat pings over persistent WebSocket connections every 30 seconds. The server registers the device in user_devices:{uid} and refreshes presence:{uid}:{device_id} with SETEX for 60 seconds, storing online for active clients and away for idle clients. If a client does not refresh the key for 60 seconds after the last successful heartbeat, the device key expires automatically. A 60 second TTL provides a bounded detection interval, but it does not inherently tolerate a missed heartbeat if the next refresh arrives after the TTL, so the hardened mobile configuration can use a longer TTL and explicit grace handling.

For multi device accounts, the server maintains separate per device keys such as presence:{uid}:{device_id}. A heartbeat refreshes the device TTL on every interval. When the device activity state changes between active and idle, or when a device expires or disconnects, the server atomically recomputes the account state and increments its revision only if the aggregate state changes. An account is considered online when any device is online. If at least one device remains connected but all connected devices are away, the account is away. It is offline only when no active device keys remain. At a scale of 200M concurrent users sending heartbeats every 30 seconds, the ingestion layer processes approximately 6.7M heartbeat messages per second. Refreshing both the device presence key and WebSocket registry produces a baseline of approximately 13.4M Redis key refresh writes per second, sharded horizontally across a Redis Cluster.

2. Expiration Detection and Repair

Redis key expiration removes stale device state, but expiration itself does not invoke application logic. The presence service therefore uses an expiry notification path or a periodic repair sweep to detect expired device keys. Notifications are treated as best effort because they are not a durable event log. The detector evaluates all device keys atomically before declaring the account offline, writes the latest last seen record asynchronously only on the account level transition, and publishes the resulting presence update. The repair sweep reconciles missed expirations after Redis failover or notification delivery loss.

3. Fan Out Optimization and Coalesced Delivery

Broadcasting raw presence transitions across social graphs produces immense write amplification that overwhelms network interfaces without aggressive filtering and coalescing.

In a naive implementation, 2M status changes per second multiplied by an average of 500 friends per user results in a crippling volume of 1B pushes per second. The production pipeline applies a multi stage reduction strategy:

• Online Only Filtering: Updates are pushed exclusively to friends who are currently online, reducing the target audience from 500 contacts to roughly 100.
• Active Chat Window Filtering: Among online friends, real time push events are restricted to contacts who currently have an active chat conversation window open with the user, cutting target recipients to approximately 15.
• Debounce Coalescing: The presence service batches and coalesces state transitions over a 5 second debounce window instead of emitting updates per change. If a user rapidly toggles between online, offline, and online within 5 seconds, friends receive only the final converged state.
• Pull on Chat Open: Contacts who open a chat conversation pull fresh presence status on demand upon opening the view, transitioning to real time pushes only while that window remains active. Together, these optimizations slash fan out volume from 500 pushes down to approximately 15 pushes per change, achieving a 33-fold reduction.

4. Last Seen Persistence and Read Paths

Last seen persistence provides historical availability data without incurring database write amplification on the hot heartbeat path.

When a device disconnects explicitly or its Redis presence key expires due to TTL exhaustion, an expiry detector evaluates all registered device keys before declaring the account offline. Only the account level online to offline transition writes the latest last seen record asynchronously to Apache Cassandra under last_seen (user_id UUID PRIMARY KEY, last_active TIMESTAMP, last_active_device TEXT, transition_revision BIGINT). Keeping this write asynchronous prevents high volume heartbeat ingestion from contending with storage I/O.

The read path evaluates status through a two tiered hierarchy. The gateway first queries the derived account presence state in Redis. If active device keys exist, the service returns online or away according to the aggregate state. If no active device key exists, the service queries Cassandra to retrieve the recorded last active timestamp and returns a formatted last seen message. If the user has enabled privacy settings to hide last seen data, the service strips the timestamp and returns only an offline indicator.

5. WebSocket Connection Routing and Gateway Registry

Distributing bidirectional WebSocket connections across thousands of gateway nodes requires an accurate, low latency connection registry.

The presence service maintains a routing registry in Redis keyed by ws_location:{uid}:{device_id}, mapping each user ID and device identifier to their connected gateway server instance. When a status update must be delivered to a recipient, the dispatch worker looks up the recipient's assigned server identifier and publishes the payload to a Redis Pub/Sub channel dedicated to that gateway node.

The recipient's gateway node consumes the message from its dedicated channel and immediately forwards the frame across the user's open WebSocket connection. When a user maintains connections across multiple devices, the dispatcher pushes messages to all registered gateway servers in parallel. On an explicit disconnect, the gateway conditionally deletes the registry entry only when the stored connection ID still matches the closing connection. The registry key carries a 60 second TTL that refreshes with each heartbeat, ensuring that crashed gateway nodes or stale connection records automatically expire without requiring manual reconciliation.