Real-Time Messaging Architecture at Slack
How Slack delivers real-time messages to millions of concurrent users using WebSocket connections, message fanout, and channel-based routing.
Quick answer: Real-Time Messaging Architecture at Slack
Real-Time Messaging Architecture at Slack is covered here as a practical system design resource. How Slack delivers real-time messages to millions of concurrent users using WebSocket connections, message fanout, and channel-based routing. Use it as a curated reference while connecting the original engineering lesson to practical system design decisions.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
Company Context
Slack is a workplace messaging platform serving millions of organizations with real-time communication. Users expect messages to appear instantly (within 100-200ms), conversations to maintain perfect ordering, and the system to handle users who are members of hundreds or thousands of channels simultaneously. Slack manages millions of concurrent WebSocket connections across its infrastructure.
The Problem at Scale
Real-time messaging has deceptively simple requirements — send a message, everyone in the channel sees it — but the implementation challenges are enormous. Each online user maintains a persistent WebSocket connection to Slack's servers. When a message is posted to a channel with 10,000 members, the system must determine which of those members are currently online, find the servers holding their WebSocket connections, and deliver the message — all within milliseconds. This is the fanout problem: one write (a message) must be delivered to many readers (channel members) with low latency.
Additionally, Slack must handle presence (knowing who is online), typing indicators (ephemeral, high-frequency events), message ordering (messages must appear in the same order for all users), and reliable delivery (if a user briefly disconnects, they must receive missed messages on reconnection).
Architecture Solution
Slack's architecture separates the concerns of connection management, message routing, and message storage.
Connection gateways are the edge layer that terminates WebSocket connections. Each gateway server handles tens of thousands of concurrent connections. Gateways are stateless in terms of business logic — they simply hold connections and forward messages.
When a message is posted, it flows through a message server that persists it to the database, assigns it a monotonically increasing sequence number within the channel, and publishes it to an internal message bus (similar to a pub/sub system). The message bus routes the message to every gateway server that has online members of that channel.
Each gateway server maintains an in-memory map of which channels each connected user belongs to. When a message arrives from the message bus for a particular channel, the gateway identifies all local connections subscribed to that channel and pushes the message down their WebSocket connections.
Presence is tracked separately: when a user connects or disconnects, a presence event is published. Slack uses a heartbeat mechanism where clients periodically confirm they are active, and the system aggregates presence state.
For reconnection, each client tracks the last sequence number it received per channel. On reconnect, the client sends these sequence numbers, and the server sends any messages with higher sequence numbers — a simple gap-fill protocol.
Key Techniques Used
- WebSocket connections: Persistent bidirectional connections for real-time delivery
- Connection gateways: Stateless edge servers that hold connections and forward messages
- Channel-based message bus: Pub/sub routing from message servers to gateway servers
- Sequence numbers: Monotonically increasing per-channel IDs for ordering and gap detection
- Fanout at the gateway: Each gateway delivers messages to locally connected channel members
- Gap-fill on reconnection: Client reports last seen sequence; server sends missed messages
- Separate presence tracking: Heartbeat-based online/offline detection, decoupled from messaging
Lessons for System Design Interviews
This is the canonical reference for "design a real-time chat system." Key points: separate connection management from message routing; use a pub/sub message bus for fanout; assign sequence numbers for ordering; handle reconnection via gap-fill. Discuss the tradeoff between push (WebSocket) and pull (polling) models. Know that the fanout problem (one message to many recipients) is the core scalability challenge.
Lessons for Production
WebSocket connection management is its own infrastructure problem — gateway servers must handle graceful connection migration during deploys. Sequence numbers per channel are critical for correctness; without them, clients cannot detect missed messages. Presence is surprisingly expensive at scale and should be approximated (e.g., "active in the last 5 minutes") rather than tracked exactly. Typing indicators and other ephemeral events should be treated differently from messages — they do not need persistence or ordering guarantees.
Original DosiBridge notes for Real-Time Messaging Architecture at Slack
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Real-Time Messaging Architecture at Slack is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Practice Loop: For Real-Time Messaging Architecture at Slack, decide the practice loop before choosing tools; otherwise the design looks clean but fails when slack changes.
- Implementation Exercise: For Real-Time Messaging Architecture at Slack, decide the implementation exercise before choosing tools; otherwise the design looks clean but fails when messaging changes.
- Review Checkpoint: For Real-Time Messaging Architecture at Slack, decide the review checkpoint before choosing tools; otherwise the design looks clean but fails when slack changes.
- Failure Drill: For Real-Time Messaging Architecture at Slack, decide the failure drill before choosing tools; otherwise the design looks clean but fails when messaging changes.
- Comparison Target: For Real-Time Messaging Architecture at Slack, decide the comparison target before choosing tools; otherwise the design looks clean but fails when slack changes.
Production review question
If a team adopts Real-Time Messaging Architecture at Slack, what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track slack-messaging health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Real-Time Messaging Architecture at Slack, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.