Design a Presence & Online-Status System

Real-Time & CollaborationMediumdesign-presence-system

Design a Presence & Online-Status System

Design the green dot: who is online, who is typing, and who just disconnected — for hundreds of millions of users whose connections drop without warning.

HeartbeatsTTL ExpirySubscription FanoutEventual Consistency

Traffic & Capacity Estimates:

50M concurrent users · 500 friends per user · status change visible within 10s

Functional Requirements

•Track per-user online, away, and offline state derived from live connections.
•Notify a user's subscribers (friends, channel members) when their state changes.
•Support ephemeral signals like typing indicators that expire on their own.
•Expose last-seen timestamps subject to the user's privacy settings.

Non-Functional Requirements

•A hard disconnect must be reflected within 10 seconds without an explicit logout.
•Presence load must not scale with the square of the social graph.
•Presence is best-effort — it must never block or slow the messaging path.

Back-of-the-Envelope Math

50M users heartbeating every 10s = 5M writes/second into an in-memory store.
Naive fanout: 50M users * 500 friends = 25B notifications per status flap — which is why subscription must be per open view, not per friendship.

Key Architectural Trade-offs

Heartbeat-with-TTL in Redis (self-healing, wrong for up to one TTL) vs explicit connection-lifecycle events (immediate, lost when a server dies unexpectedly).
Push presence to all friends (instant, quadratic) vs fetch presence for only the users currently rendered on screen (bounded, adds a read per view).
Presence is high-churn, low-value data: storing it durably is a design smell, but losing it all in a Redis failover has to be survivable.

Click or drag a component onto the canvas, then connect the handles to draw the data flow.

3 nodes · 2 edges

Components · 35

Client & Edge4

Compute & Gateway7

Storage & Caching11

Messaging & Streaming6

Coordination & Ops5

Intelligence2

React Flow