Slack

Overview

Slack is a channel-based messaging platform that transformed workplace communication. Serving millions of daily active users across 750,000+ organizations, Slack’s architecture must support real-time message delivery, powerful full-text search across years of message history, enterprise compliance requirements, and cross-organization collaboration via Slack Connect. Built as a PHP monolith that evolved into a service-oriented architecture, Slack’s engineering emphasizes reliability, searchability, and deep third-party integrations.

Scale

Requirements

High-Level Architecture

Loading diagram...

Key Components

Data Model

Loading diagram...

Channel Fanout and Real-time Delivery

When a user posts a message to a channel, Slack must deliver it to every online member of that channel in real time. This is the channel fanout problem.

1. Message ingestion: The message hits the Message Service, which persists it to MySQL and publishes an event to the internal message bus.
2. Fanout service: A dedicated service reads the channel’s membership list and determines which gateway servers hold WebSocket connections for those members.
3. Targeted push: Instead of broadcasting to all gateways, Slack routes the message only to the specific gateway servers that have connected members — a targeted fanout approach.
4. Client update: Each gateway pushes the message over the member’s WebSocket connection. The client inserts it into the correct channel view.

For very large channels (10K+ members), Slack uses a lazy loading strategy — only members who currently have the channel open receive the message immediately. Others see an unread indicator and fetch messages on demand.

Loading diagram...

Search Architecture

Slack’s search is a critical differentiator — users expect to find any message or file ever shared, instantly.

Indexing pipeline: Messages are asynchronously indexed into Elasticsearch after being written to MySQL. The index includes message text, sender, channel, timestamps, and file metadata. Slack shards its Elasticsearch indices per-workspace for isolation.

Access control: Search results are filtered by the requesting user’s channel memberships. This is enforced at query time by intersecting search hits with the user’s accessible channel set.

Query parsing: Slack supports structured queries like from:alice in:#engineering after:2024-01-01 has:link. These are parsed into Elasticsearch bool queries with the appropriate filters.

Ranking: Results are ranked by a combination of recency, relevance (BM25), and social signals (reactions, thread replies). Recent messages in active channels are boosted.

Vitess-based MySQL Sharding

Slack’s primary data store is MySQL, sharded using Vitess to scale horizontally.

Sharding strategy: Data is sharded by workspace ID, so all data for a single workspace lives on the same shard. This keeps most queries (channel lists, message history, membership) shard-local.

Why Vitess?: Slack migrated from a hand-rolled sharding layer to Vitess for its connection pooling, query routing, and online schema migration capabilities. Vitess handles thousands of MySQL instances behind a unified query interface.

Large workspace handling: Enterprise Grid workspaces with 500K+ users require dedicated shards. Slack’s infrastructure can split and rebalance shards without downtime.

Caching layer: Memcached sits in front of MySQL for hot data — channel membership lists, user profiles, and workspace settings. Cache invalidation is event-driven.

Architectural Tradeoffs

# Learn From a Slack-like System

You are an expert software architect and teacher. I want to learn from a Slack-inspired system design (Channel-based messaging for the enterprise workplace) without pretending this is the exact private production architecture.

Use the following reference as a learning model. Keep assumptions visible, avoid unsupported scale claims, and explain the engineering forces behind each design choice.

---

## System Design Reference
import { Mermaid, Scale, ComponentList, ComponentCard, Requirements, Tradeoff } from '@/components/mdx';

## Overview

Slack is a channel-based messaging platform that transformed workplace communication. Serving millions of daily active users across 750,000+ organizations, Slack's architecture must support real-time message delivery, powerful full-text search across years of message history, enterprise compliance requirements, and cross-organization collaboration via Slack Connect. Built as a PHP monolith that evolved into a service-oriented architecture, Slack's engineering emphasizes reliability, searchability, and deep third-party integrations.

## Scale

<Scale items={{
  "Daily active users": "30M+",
  "Messages sent per day": "1.5B+",
  "Connected apps & integrations": "2,600+",
  "Paid customers": "200,000+",
}} />

## Requirements

<Requirements
  functional={[
    'Channel-based messaging (public, private, DM, group DM)',
    'Threaded conversations within channels',
    'Full-text search across all messages and files',
    'File sharing and previews',
    'App integrations and slash commands',
    'Slack Connect for cross-organization channels',
    'Reactions, mentions, and rich message formatting',
  ]}
  nonFunctional={[
    'Real-time message delivery (<500ms)',
    'High availability (99.99% SLA for Enterprise Grid)',
    'Compliance — message retention, eDiscovery, DLP',
    'Horizontal scalability for large organizations (500K+ users)',
    'Searchable message history spanning years',
    'Dat...

[Full prompt copied to clipboard]