Real-Time Team Chat System Design for Slack: Channels, Delivery and Message History

Quick Overview

A system design prompt from a product manager interview: design Slack, the workplace chat app with workspaces, channels and direct messages delivered in real time. It tests scale assumptions, real-time delivery and fan-out, message storage and ordering, offline sync, and failure handling.

Real-Time Team Chat System Design for Slack: Channels, Delivery and Message History

Company: Slack

Role: Product Manager

Category: System Design

Difficulty: medium

Interview Round: Other

Design Slack: the system behind a workplace messaging app where members of a workspace talk in channels and direct messages and see new messages appear in real time. ```hint Follow one message Trace a single message from the moment the sender presses Enter until it shows up for every member of a busy channel, including members who are offline or signed in on two devices. Each hop on that path is something you need to design. ``` ### Clarifying Questions - Which features are in scope: channels and direct messages only, or also threads, reactions, file sharing, search and integrations with other apps? - How big can a workspace and a single channel get: a small team, or an enterprise where one channel holds every employee? - What delivery guarantees matter: must a message be stored before the sender sees it as sent, and must everyone in a channel see messages in the same order? - Should full message history be available on every device a person signs in from? ### What a Strong Answer Covers - Requirements and scale assumptions stated up front (workspace and channel sizes, message rates, read and write mix) and how they shape the design. - The real-time path: long-lived client connections, knowing which server holds each user's connection, and fan-out to channel members, including very large channels. - A data model and storage choice for workspaces, channels, memberships and messages, with per-channel ordering and paged history. - Offline users, multiple devices, unread counts, notifications, and reconnects without lost or duplicated messages. - Scaling, failure handling and observability, with the trade-offs a PM should weigh, such as consistency versus latency. ### Follow-up Questions - An enterprise workspace has one announcement channel that every employee belongs to. What breaks in your design, and how would you change delivery for that channel? - How would you add search over a workspace's message history, and how fresh does the index need to be? - A customer requires that its messages stay in one geographic region and are deleted after a fixed period. What changes in storage and in the delete path?

Overview: A system design prompt from a product manager interview: design Slack, the workplace chat app with workspaces, channels and direct messages delivered in real time. It tests scale assumptions, real-time delivery and fan-out, message storage and ordering, offline sync, and failure handling.

Slack logo
Slack
Mar 17, 2026
mediumProduct ManagerOtherSystem Design
0
0

Design Slack: the system behind a workplace messaging app where members of a workspace talk in channels and direct messages and see new messages appear in real time.

Clarifying Questions Guidance

  • Which features are in scope: channels and direct messages only, or also threads, reactions, file sharing, search and integrations with other apps?
  • How big can a workspace and a single channel get: a small team, or an enterprise where one channel holds every employee?
  • What delivery guarantees matter: must a message be stored before the sender sees it as sent, and must everyone in a channel see messages in the same order?
  • Should full message history be available on every device a person signs in from?

What a Strong Answer Covers Guidance

  • Requirements and scale assumptions stated up front (workspace and channel sizes, message rates, read and write mix) and how they shape the design.
  • The real-time path: long-lived client connections, knowing which server holds each user's connection, and fan-out to channel members, including very large channels.
  • A data model and storage choice for workspaces, channels, memberships and messages, with per-channel ordering and paged history.
  • Offline users, multiple devices, unread counts, notifications, and reconnects without lost or duplicated messages.
  • Scaling, failure handling and observability, with the trade-offs a PM should weigh, such as consistency versus latency.

Follow-up Questions Guidance

  • An enterprise workspace has one announcement channel that every employee belongs to. What breaks in your design, and how would you change delivery for that channel?
  • How would you add search over a workspace's message history, and how fresh does the index need to be?
  • A customer requires that its messages stay in one geographic region and are deleted after a fixed period. What changes in storage and in the delete path?