Part 4 · 2 chapters · ~12 min

Chat and Presence

One-to-one and group chat with persistent connections, ordered delivery per conversation, offline sync, storage partitioned by conversation, and approximate presence.

9

Brief, questions and numbers

the brief
  1. Users send messages to individuals and groups in real time, see delivery and read receipts, and see who is online.
questionanswer we assume
users?20M daily active, 5M concurrent connections at peak
messages?1B/day
ordering?per conversation, not global
history?kept for years, synced across devices
groups?up to 1,000 members
code
messages   = 1B/day ≈ 11,600/s average, ~40,000/s peak
connections= 5M concurrent / 100k per gateway node ≈ 50 gateway nodes
storage    = 1B × 300 B ≈ 300 GB/day ≈ 110 TB/year (replicated ×3)
presence   = 5M keys refreshed every 30 s ≈ 170k Redis writes/s: shard it
CHAT AND PRESENCE
persistent connections on gateway nodes, messages through a log, presence with heartbeats
user AWebSocketgateway 1holds Agateway 2holds Buser BWebSocketmessage servicevalidate, order, storeCassandra / Scyllaby conversation, timepresenceRedis, TTL heartbeats
swipe the figure sideways, or tap expand for full screen
1/5
connections
Clients keep a WebSocket to a gateway node. Each node holds hundreds of thousands of mostly idle connections; a registry maps user to gateway.
long-lived sockets on gateway nodesa registry: user → gateway
10

v1, the break, and v2

v1. Clients poll a REST endpoint every few seconds; messages live in one Postgres table indexed by conversation and time.

The break. Polling 20M users every 3 seconds is millions of requests per second of mostly empty responses, and a single Postgres table cannot absorb 40k writes per second plus history reads.

v2. WebSocket gateways with a user-to-gateway registry, a message service assigning per-conversation sequence numbers, a wide-column store partitioned by conversation, pub/sub between gateway nodes, push notifications for offline users, and TTL-based presence in sharded Redis.

the sentence
v2 buys real-time delivery and linear storage scaling, and pays with stateful gateway nodes to drain during deploys and an eventually consistent presence view.