Design Slack

Problem statement

Design a workspace-centric team communication platform: public and private channels, direct messages, group DMs, threads, reactions, edits and deletes, file sharing with link previews, full-text search across messages and files, real-time presence and typing indicators, and a third-party app ecosystem with slash commands, bots, and event webhooks. Every artifact lives inside a workspace (or an enterprise organization spanning workspaces), and thousands of members of one organization can share a single channel. The system must deliver a message to every online member of a conversation in under a second, persist it durably for years, and make it searchable within seconds, while isolating tenants from each other's load and data.

The defining engineering tension is fan-out asymmetry. A direct message has two participants; an announcement channel in an enterprise grid can have hundreds of thousands of members across dozens of workspaces. One write therefore becomes anywhere from one to hundreds of thousands of deliveries, and the read pattern is equally skewed: most reads are recent history on a small number of hot channels. A naive per-recipient inbox (write fan-out to every member) collapses on mega-channels; a pure pull model adds latency and read amplification for the long tail of small conversations. The architecture must choose a delivery strategy per conversation, per moment, and be able to change it as channels grow.

Why the problem is distinctive

A notification system fans out to devices; Slack fans out to conversation memberships with strict per-conversation ordering, edit/delete semantics, and permission visibility (private channels, shared channels across organizations). A social feed tolerates ranking and loss; a team chat is a system of record: messages are durable, ordered, editable with visible history, retention-controlled, and exportable for compliance. Presence and typing are ephemeral high-churn state that must never be allowed to destabilize the durable message path. Search must respect channel membership at query time, which turns a text query into a security-filtered query over billions of documents.

Public operating baseline versus design assumptions

Public evidence shows the category operates at extreme scale. Slack announced more than 10 million daily active users across more than 600,000 organizations, and its earnings disclosures reported 12.5 million simultaneously connected users on March 25, 2020; publicly reported figures put Slack above 1.5 billion messages per day. Discord's engineering blog describes delivering more than 26 million WebSocket events per second to more than 12 million concurrent users through an Elixir gateway, and storing trillions of messages in ScyllaDB. WhatsApp's public talks describe Erlang nodes handling on the order of two million simultaneous connections each. These are cited company figures, not requirements for our fictional system.

For capacity planning this answer explicitly assumes a mature platform with 40 million DAU, 15 million peak concurrent socket connections, 1.5 billion messages per day, and a 5x work-hour peak multiplier. Unless a number is tied to a citation, it is a stated design assumption, target, budget, or illustrative threshold.

The five architectural planes

1. Connection plane: WebSocket gateways, session resume buffers, presence aggregation, push bridges.
2. Conversation plane: message ingest, per-conversation sequencing, durable conversation log, fan-out dispatch.
3. Workspace plane: multi-tenant identity, membership, permissions, enterprise grid and shared channels.
4. Discovery plane: search indexing and query, file storage, link previews.
5. Platform plane: OAuth apps, slash commands, interactions, events API webhooks, admin and compliance tooling.

A strong interview answer keeps these planes separate: the ephemeral connection plane may degrade without corrupting the durable conversation plane, and the platform plane must never sit in the hot message path.