Slack

Assume 50M daily active users across many workspaces, 5M average concurrent WebSocket connections, 15M peak concurrent connections, and 1B messages per day. Average channel messages are delivered to 20 online or recently active members, but a small number of huge channels can have 100K or more members.

Assume each persisted message record averages 2 KB before replication and search indexing. The record includes workspace id, channel id, message id, channel sequence, sender, timestamps, thread root, text pointer, edit metadata, retention flags, and small attachment metadata. Large file bytes are stored separately.

• Message writes: 1B messages per day divided by 86,400 seconds is about 11,574 writes per second, rounded to 11,600. A 10x peak gives about 116,000 writes per second.
• Real-time fanout: if each message has 20 online or recently active recipients, average delivery attempts are 11,600 times 20, or about 231,000 per second. Peak delivery attempts are about 2.3M per second before special handling for huge channels.
• Storage: 1B messages times 2 KB is about 2 TB raw message data per day. For one year, 2 TB times 365 is about 730 TB raw. With 3 replicas, compaction overhead, indexes, and retention metadata, plan for multiple petabytes.
• WebSocket state: 15M peak connections times roughly 8 KB of gateway connection state is about 120 GB of memory before runtime overhead, TLS buffers, and per-process overhead. This requires many gateway hosts and careful connection sharding.
• Presence: 15M peak connections with one heartbeat every 30 seconds creates 500,000 heartbeat events per second. Gateways should aggregate and suppress unchanged presence updates.
• Read cursors: 50M users times 100 channel cursor updates per day is 5B cursor updates per day. 5B divided by 86,400 is about 57,870 writes per second. Coalescing and idempotent upserts are important.
• Huge channels: a 100K-member announcement channel cannot be treated like a 20-member project channel. The system should deliver to online members immediately, materialize history once, and compute unread state lazily where possible.

• messages(workspace_id, channel_id, channel_sequence) is the main history index and supports ordered pagination.
• messages(workspace_id, thread_root_message_id, channel_sequence) supports thread views without scanning the whole channel.
• channel_memberships(workspace_id, user_id) lists a user's channels for sidebar rendering and reconnect subscription.
• channel_memberships(workspace_id, channel_id, user_id) authorizes send, history, and search result visibility.
• channels(workspace_id, name) is unique for public and private named channels.
• The search index stores tokenized message text with workspace id, channel id, message id, created_at, and access-filter metadata. Search results must still be permission checked.

A workspace owns channels, memberships, messages, retention policies, and audit logs. A channel has many memberships and many messages. A DM is modeled as a channel with fixed membership, which keeps message storage and unread logic uniform. Message edits and deletes are best represented as new events linked to the original message id so compliance systems can reconstruct history when policy requires it.

At production scale, the message log is better served by a distributed wide-column or log-structured store such as Cassandra, DynamoDB, Bigtable, or a custom append log. Partition by workspace and channel, order by channel_sequence, and split very hot channels into time buckets or virtual shards while preserving a logical sequence.

Membership and read cursors can live in a low-latency key-value store with write coalescing. Presence should be ephemeral in Redis or a purpose-built in-memory state service, not in the durable message database. Search belongs in OpenSearch, Elasticsearch, Vespa, or a similar inverted index fed from the message event stream. Compliance archives can be stored in immutable object storage with tenant-specific retention policies.

Slack users expect everyone in a channel to agree on message order. The simplest mental model is an append-only log per channel: each accepted message receives a monotonically increasing channel_sequence, and clients render messages by that sequence.

A single global order is unnecessary and harmful because two unrelated channels do not need to coordinate. Per-channel ordering lets the system partition by channel, scale independent hot paths, and make replay straightforward. The hard part is hot channels. A channel with very high write QPS can bottleneck on one sequencer or partition.

Common mitigations include partition-local log offsets, a lightweight per-channel sequencer, leasing sequence ranges to a leader, or splitting huge announcement channels into virtual fanout shards while preserving one logical display order. Edits and deletes should not reorder the log; they are versioned events attached to the original message.

Small channels can use push fanout: when a message is committed, fanout workers resolve online members and push the event to each active connection. This gives low latency and simple client behavior.

Huge channels need a different approach. Pushing a single message to 100K members synchronously can overload membership stores, WebSocket gateways, and network links. For announcement channels, deliver immediately to online users in batches, shard by gateway, and let offline users catch up from the channel log. Avoid writing one inbox row per recipient unless a product feature truly requires it.

A strong answer separates durable history from delivery attempts. The message exists once in the channel log. Real-time delivery is a best-effort acceleration for online users. This keeps the system closer to Slack than to an email queue.

Unread state is deceptively expensive. A naive design increments a counter for every member on every message. That explodes for huge channels and creates high write amplification.

A better design stores a per-user per-channel last_read_sequence and computes unread as latest_channel_sequence minus last_read_sequence, adjusted for joins, deletes, muted channels, and mention-only counters. For small channels or sidebar performance, maintain cached summary counters that can be repaired from the authoritative cursor and message log.

Mention counts are separate from general unread counts. Mentions are sparse enough to materialize as per-user mention events, but they still need deduplication, retention handling, and mute logic. Cursor writes should be idempotent and monotonic so repeated client updates are safe.

Presence is high-volume and low-criticality. At 15M peak connections and one heartbeat every 30 seconds, the raw heartbeat stream is about 500K events per second. Persisting every heartbeat would be wasteful.

Realtime Gateways should aggregate heartbeats locally, publish only state changes, and use TTLs for liveness. The Presence Service stores ephemeral device and user state in memory or Redis, then emits coarse deltas such as active, away, or offline. Clients do not need second-by-second accuracy.

Degrade presence first during incidents. Messaging should remain available even if presence is stale or disabled. Interviewers like to see this priority because it shows that not all real-time features have the same reliability target.

Search is essential in Slack because channels form an organizational memory. The message send path should publish durable events to an indexing pipeline. Indexers tokenize text, extract mentions and attachments, apply language analyzers, and store workspace id, channel id, message id, timestamp, and access metadata.

Search must enforce permissions. A user should never see private-channel or DM results after leaving the channel unless policy explicitly allows it. This can be enforced with filtered queries over membership, per-tenant index partitions, or secure document-level access filters.

Enterprise compliance adds retention, legal hold, immutable audit history, and eDiscovery exports. Deletes may hide content from normal users while preserving it for legal hold. Therefore, the system needs policy-aware storage rather than a single hard-delete path.

Every layer should know the workspace boundary. API auth, message partitions, search indexes, encryption keys, audit logs, quotas, and operational dashboards should be scoped by workspace or enterprise organization.

Isolation protects privacy and reliability. A large customer's export job, search spike, or huge channel should not starve smaller tenants. Apply per-tenant rate limits, queue partitions, storage quotas, and noisy-neighbor controls. For highly regulated customers, isolate indexes, keys, or even clusters by enterprise tier.

This is another major contrast with WhatsApp. Slack's core unit is the workspace with admin policy and channels; WhatsApp's core unit is personal conversations. That difference drives the whole HLD.

Alternative one is fanout-on-write to per-user inboxes. It makes each user's unread and sidebar views fast, but it explodes for huge channels and creates many writes per message.

Alternative two is pure fanout-on-read from channel logs. It minimizes write amplification and works well for offline users, but online real-time delivery and unread badges need additional caches and event streams.

Alternative three is an end-to-end encrypted personal messenger model. It improves message privacy from the provider, but it conflicts with Slack-like enterprise search, retention, moderation, and eDiscovery requirements.

Do not use this design when the product requires default provider-blind end-to-end encryption for personal conversations. Slack-like workspace messaging intentionally supports organizational search, admin policy, compliance exports, and integrations, which require different tradeoffs from private personal messaging.