Design Slack-like Chat System

Slack is a workplace messaging platform that enables users to exchange direct messages and create topic-based group channels. Users can share text and media, with notifications delivered in real time across multiple devices.

We are designing the core messaging layer: direct messages between two users and group channels whose membership can range from a few people to tens of thousands. The central challenge is that small conversations benefit from eager push delivery for a real-time feel, while per-message push in massive channels is prohibitively expensive and requires a fundamentally different approach.

Functional requirements

• Users can send direct messages (DMs) to another individual user.
• Users can create a group channel and manage its membership (add or remove members).
• Users can send text messages with optional image attachments to a channel; the message is delivered to all members.
• Online users receive new messages in real time through persistent connections.
• Users can delete their own messages (a soft delete that other participants can see).

Out of scope (below the line)

• Threaded replies and message threading
• Message reactions, emoji, and editing
• Voice and video calls
• File sharing beyond images
• Channel discovery and public channels
• End-to-end encryption
• Typing indicators and presence
• Mobile push notification pipeline (APNs / Firebase Cloud Messaging)
• Multi-region deployment

Non-functional requirements

• Messages reach online recipients within 200ms for DMs and small channels, and within 500ms for large channels.
• Target 99.9% uptime for the message send path. Sends always succeed even if some delivery paths degrade.
• Once the server accepts a message, it must never be lost. Persist before acknowledging the send.
• Support 50M daily active users, approximately 1B messages per day, with channels ranging from 2 members (DM) to 100K+ members.
• Messages within a single channel appear in consistent order across all clients.
• Users logged in on multiple devices receive messages on all active sessions.

Assumptions

• A DM is modeled internally as a two-member channel.
• Channel membership is invite-only. No public channel discovery.
• Rich media means image uploads only. Videos and files are out of scope.
• Deletion is soft: the message body is replaced with a "deleted" marker.
• Single-region deployment for this design.
• User authentication and profiles are assumed to exist.

Back-of-the-envelope estimation

The connection count confirms that a single server cannot hold all WebSocket connections. A fleet of gateway servers is required, with a routing layer to deliver messages to the correct server. The message volume confirms that the storage layer must handle sustained high write throughput, making Cassandra a natural fit for the message log. The channel size range is the most consequential number: delivering to a 5-person DM is fundamentally different from delivering to a 100K-member announcement channel, and the architecture must handle both.

Slack Real-Time Messaging Architecture