Skip to content

How a Slack-like workplace messenger might evolve

A message typed in one office must appear on every member's screen within a fraction of a second, be searchable forever, and respect enterprise permissions. How persistent connections, channel fan-out, search and compliance shape a workplace messenger.

The user problem and the hard parts

A team wants conversations that feel instant, are never lost, can be found months later, and are visible only to the right people. Their company's IT and legal teams want control: single sign-on, retention policies, audit exports.

The hard engineering problems:

  • Real-time delivery: plain HTTP is request/response, so the server can't push. Clients keep a persistent WebSocket connection (a full-duplex channel over one connection) to a gateway, and millions of those connections must be managed.
  • Channel fan-out: one message in a 10,000-member channel must reach every online member's connections, wherever they are connected.
  • Ordering and gaps: clients reconnect constantly (laptops sleep, phones switch networks). They must catch up on missed messages without duplicates or holes.
  • Search: years of messages per workspace, with results filtered by what this user is allowed to see.
  • Enterprise permissions: private channels, guest accounts, shared channels between companies, retention, legal hold, data residency.

How the architecture might evolve

A Slack-like workplace messenger

A plausible architecture for a workplace messaging product at each scale. Slack has published engineering posts on its real-time gateways and on sharding with Vitess; details here are illustrative.

  1. 1
    Stage 1 · Startup teams
    1k workspaces · 50k users
    Web/desktop clientMonolith API (e.g. PHP or Node)MySQL/PostgreSQLOne WebSocket server process poolFull-text search in the database

    Keeping all of a workspace's data in one database makes permissions simple joins. A single pool of socket servers can hold every connection.

  2. 2
    Stage 2 · Growth
    100k workspaces · 2M daily users
    Dedicated gateway tier for WebSocketsPub/sub layer (e.g. Redis) to route messages to gatewaysDatabase sharded by workspaceDedicated search clusterJob queue for notifications, unfurls, file processing

    Connections are long-lived state, so they move to their own tier that can scale and deploy separately from the API. Workspace is a natural shard key because most queries stay inside one workspace.

  3. 3
    Stage 3 · Enterprise
    Very large companies · channels with 100k+ members
    Channel servers that own fan-out per channel (consistent hashing)Gateways in multiple regions near usersFiner-grained sharding (by channel/user) via a sharding layerPermission-aware searchEnterprise key management, retention and legal hold

    A huge enterprise outgrows the one-shard-per-workspace model, so data is split more finely. Fan-out moves to dedicated channel servers so one huge channel doesn't overload a generic tier.

  4. 4
    Stage 4 · Connected companies
    Shared channels across organisations
    Cross-organisation channel model with per-org policiesData residency per regionEvent stream for integrations and auditCellular architecture to limit blast radius

    A channel shared by two companies obeys two sets of retention and access rules. Isolation by cell keeps an incident in one region from becoming a global outage.

A message's journey to 5,000 screens

A plausible architecture for Stage 3 might look like this. Note how persistence and delivery are separate steps.

Click a component

Click any component to see what it does.

Deep dive: search that respects permissions

Search is where permission bugs leak data. A user who left a private channel yesterday must not find its messages today.

Two common approaches:

  1. Filter at query time: the index stores the channel id per message; the query adds a filter "channel in (channels this user can read now)". Always current, but the list can be large for big enterprises, so it is cached and invalidated on membership changes.
  2. Pre-computed access lists in the index: each document stores who can see it. Fast queries, but every membership change means reindexing many documents.

Most designs use query-time filtering with a cached membership set, plus a post-filter on the final page of results as a last line of defence. Enterprise features add -based SSO (single sign-on) via the company's identity provider, SCIM (System for Cross-domain Identity Management) for automatic deprovisioning, and retention jobs that physically delete messages and their index entries.

Engineering trade-offs

Polling

  • Works everywhere, stateless servers
  • Trivial to load-balance
  • Latency equals the poll interval
  • Wasted requests when nothing changed
Choose when: Low-frequency updates, or a fallback when sockets are blocked.

WebSockets through a gateway tier

  • Sub-second push
  • One connection for all events
  • Stateful tier: deploys must drain connections
  • Reconnect storms after an outage
Choose when: Chat, presence, collaborative editing.

Shard by workspace

  • Most queries hit one shard
  • Simple permission joins
  • Giant enterprises create hot shards
  • Shared channels across workspaces are awkward
Choose when: Many small and medium workspaces.

Shard by channel or user

  • Spreads giant tenants
  • Better balance
  • Workspace-wide queries fan out across shards
  • Needs a routing layer
Choose when: Enterprise customers whose single workspace exceeds a shard.

Practical exercise

The reconnect storm

A gateway deploy goes wrong and 2 million clients are disconnected at once. They all reconnect within ten seconds, each fetching its missed messages and full channel list. The API and databases collapse, which disconnects more clients. How do you break the loop and prevent it next time?