Design Slack (team chat)

Each message must reach every online member of the channel on every device. Fan-out per user (like a timeline) is wasteful here because channels are shared spaces with persisted history. Instead, Slack-style systems have stateful channel servers: channel IDs are assigned to channel servers by consistent hashing, and each channel server keeps, for its channels, the set of gateways that currently have a subscribed member. When a user connects, their gateway subscribes to all their channels (a user can be in hundreds, so subscriptions are batched). Sending a message is then one publish to the owning channel server, which forwards once per subscribed gateway, and each gateway pushes to its local connections. For a 100k-member announcement channel with 60k online, that is a few hundred gateway messages, not 60k RPCs. Channel servers keep only soft state; if one dies, its channels are re-hashed and gateways resubscribe. Slack's real architecture has this split of gateway servers and channel servers, plus admin and presence servers, and gateway regions close to users with the channel servers in the core region.

History reads are the main pattern: 'latest 50 messages in channel X', then page backwards. So the primary key is (channel_id, ts), which makes it a single range scan. Sharding by workspace_id is natural for tenant isolation, backups and data residency, and keeps all of a company's data together for exports and compliance. But a huge enterprise workspace then becomes a hot shard. A better long-term choice is sharding by channel_id with a routing layer (Vitess with a lookup vindex), so big workspaces spread across shards while small ones are still cheap. The ts is a per-channel ordered identifier; generating it in the database row of the channel, or using a Snowflake-like ID with a tie-break, gives a stable total order per channel, which is the only order users see. Edits and deletes are updates to the row plus an event; deletes may be soft for retention and legal hold. Enterprise retention policies (delete after 90 days) run as background jobs per workspace. Thread replies are messages with thread_root_ts set, plus a reply count and participants list on the root to render 'N replies'.

Storing a read/unread flag per message per user would mean a write for every member on every message, which explodes for big channels. Instead store a last_read_ts per (user, channel). Whether a channel has unread messages is simply 'latest message ts > last_read_ts', which is cheap if you cache each channel's latest ts. Exact unread counts are harder; most products show a bold channel name and only count mentions exactly. Mentions are rare relative to messages, so incrementing mention_count for each mentioned user (including @here and @channel fan-out, which you must rate-limit in big channels) is affordable; it resets when the user reads up to that point. At startup the client loads counts for all its channels in one call from Redis. Read markers sync across devices through the user's own real-time connections. This 'pointer, not flags' approach is the main insight interviewers look for in any chat or inbox design.

Search must never show a message from a private channel the user is not in, and results change when users join or leave channels. Index messages in Elasticsearch routed by workspace_id so a query only touches that tenant's shards. At query time, fetch the user's channel IDs (hundreds, maybe thousands) and add them as a terms filter, so the filter is enforced inside the search engine rather than after fetching results, which avoids empty pages and leaks. For users in many thousands of channels, split into public channels (filter by 'is_public and workspace') plus the private list. Index via Kafka consumers so indexing never slows down sending; target under 10 s lag. Edits re-index the document; deletes remove it. Ranking mixes text relevance with recency and how close the author or channel is to the searcher. Large enterprises may require their own index cluster or encryption with their own keys, which tenant routing makes possible.

Unlike WhatsApp, Slack stores everything on the server so any device sees full history and search works. The cost is that the server can read content, so security relies on encryption at rest, access controls and optional customer-managed keys rather than E2E encryption.

Workspace sharding gives isolation and easy per-tenant operations but creates hot shards for giant tenants. Channel sharding spreads load but makes workspace-wide operations multi-shard. A routing layer that supports both (small tenants together, big ones spread) is the practical answer.

Exact counts per channel need counting messages after a pointer, which is costly for busy channels. Showing 'has unread' plus exact mention counts gives users what they need cheaply.

Redis pub/sub works for an MVP. At large scale, custom channel servers give control over subscription batching, ordering and backpressure. Kafka is still used for durable async work like indexing and notifications.

Millions of clients connect and each subscribes to hundreds of channels and loads counts. Use jittered connection, lazy loading (only the open channel's history), cached counts, and batched subscriptions. Slack built an edge cache (Flannel) of workspace data near users to cut this boot cost.

One message triggers 100k notifications. Restrict @channel in large channels to admins, queue notifications through workers with rate control, and collapse multiple mentions into one push.

Move the tenant's busiest channels to dedicated shards via the routing layer; isolate their search index.

Consistent hashing moves its channels to other servers; gateways detect it and resubscribe. Clients may miss a few seconds of live events, so they fetch messages since their last seen ts after resubscribe. The database still has everything.

Messages are still sent and shown; only search is stale. Alert on consumer lag; the UI can show 'recent messages may not appear yet'.

Sends to channels on that shard fail for seconds; clients keep messages in pending state and retry with the same client_msg_id, so no duplicates after recovery.