Design a Social Presence Service

Problem statement

Design a social presence service that shows, in real time, whether each user is online, idle, or offline across a social or messaging platform, tracks sessions across multiple devices per user, exposes last-seen timestamps where privacy allows, and integrates with push notifications so the rest of the platform knows how to reach a user. The service must propagate presence changes to interested observers with sub-second latency at peak, survive gateway failover without flapping every user to offline, and scale to tens of millions of concurrently connected devices.

Presence looks trivial until you name its true shape: it is a continuously changing, per-user, multi-device, privacy-filtered projection of connection and activity state, fanned out over the edges of a social graph that includes ordinary friend lists and accounts with hundreds of thousands of followers. Every app open, background, lock, crash, network handoff, and server restart produces state churn. The system therefore has two very different workloads: a write-heavy churn path (sessions, heartbeats, transitions) and a read-heavy distribution path (friend lists rendering, chat headers, subscriber streams). A strong design treats these as separate planes with different consistency, storage, and failure semantics.

Why this problem is distinctive

A profile service can retry a write. Presence cannot be retried into correctness: a stale online dot erodes trust just as much as a flapping one. The design must therefore separate three planes. The connection plane owns sockets, heartbeats, and session liveness. The presence computation plane aggregates device sessions into one user-level state with idle and offline rules. The distribution plane decides, per observer and per privacy policy, whether a change is pushed, pulled, coarsened, or hidden. Mixing these planes produces the classic failures: heartbeat writes hammering a relational database, follower fan-out storms when a celebrity goes offline, and mass offline flaps during a single gateway deploy.

Public operating baseline versus design assumptions

Public evidence shows the category operates at enormous scale. Facebook built its 2008 chat on clustered Erlang and ejabberd precisely because presence and buddy-list fan-out were the hard part, scaling the feature to roughly 70 million users at rollout. WhatsApp's Erlang nodes were reported to hold over two million concurrent connections per server while carrying tens of billions of messages per day. Discord publicly described scaling its Elixir gateway to five million concurrent users in 2017 and later beyond ten million, with the gateway owning heartbeats and real-time fan-out. Slack's engineering blog describes an edge cache, Flannel, and industry coverage of Slack's architecture reports more than five million simultaneous WebSocket sessions at peak weekday hours. These are cited public figures, not requirements for our fictional system.

For capacity planning this answer explicitly assumes a mature social platform with 500 million registered users, 200 million MAU, 90 million DAU, 30 million peak concurrent connected users, and 1.4 devices per active user, yielding about 42 million peak concurrent sessions. Unless a number is tied to a citation, it is a stated design assumption, target, or budget.

The correctness contract

The service is judged by five behaviors: changes propagate fast when they matter; absence of signal degrades to offline only after an explicit grace period; multi-device reality aggregates correctly (any active device means online); privacy rules are evaluated on every read and every fan-out; and failover never converts one node death into a platform-wide offline event.