Design a Slack-Like Messaging Platform

Q: Design a Slack-Like Messaging Platform

This question evaluates a candidate's competency in designing scalable, low-latency distributed messaging architectures, covering conversation modeling, per-conversation ordering and idempotency, real-time and offline delivery, history and pagination, file handling, APIs, data partitioning, multi-region consistency, security/ACLs, and operational concerns. As a System Design domain prompt, it is commonly asked to probe trade-offs between consistency, availability, latency, and scale while assessing both conceptual architectural reasoning and practical application details such as APIs, data models, deployment, monitoring, and backpressure handling.

Q: How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

Q: What difficulty level is this interview question?

This is a easy difficulty System Design question, commonly asked during Onsite rounds at Crusoe.

Q: What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Crusoe during technical interviews.

Question

Problem Statement

Design a Slack-like team messaging platform that serves millions of daily active users with low-latency delivery across multiple regions.

Your design must support a conversation model built from workspaces/organizations, public and private channels, one-to-one direct messages, and group chats with many members. Within those conversations, users send, receive, edit, and delete messages, and the system must guarantee per-conversation ordering along with deduplication and retry safety. Messages are delivered to online users in real time (e.g., over WebSockets), reach offline users via push notifications, and let any client catch up after a reconnect. The platform also stores message history (paginated, multi-device synced), supports file sharing, and layers on collaboration features such as threading, reactions, @mentions, full-text search, presence/typing indicators, and retention.

Produce an end-to-end design covering: the conversation model; the message send/edit/delete path with ordering, dedup, and retries; real-time delivery and fanout for both small and very large channels; offline delivery, push, and reconnect catch-up; history retrieval, pagination, and multi-device sync; file upload/download/preview; the prioritized collaboration features (justify what you build first); the public APIs (send, history, subscribe/stream, search); the data model and how messages are partitioned and ordered; the non-functional requirements (latency, scale, HA, multi-device consistency, multi-region, security/ACLs); and operational concerns (monitoring, backpressure, abuse/rate limiting).

Constraints & Assumptions

Scale: millions of daily active users; the largest workspaces have hundreds of thousands of members. Most channels are small, but the largest can have tens of thousands of members steady-state — and a company-wide announcement channel or a live event can briefly push a single channel toward ~100k concurrently active members.
Latency target: for two online users in the same region, p99 send-to-deliver should be a few hundred milliseconds or less.
Durability: an acknowledged message must never be lost; ordering within a single conversation must be stable across all devices.
Availability: tolerate single-node and single-zone failures with no message loss.
Multi-region: users connect from many regions; the design should keep ordering simple while still surviving a regional outage.
Ordering scope: assume a per-conversation total order is sufficient — a global cross-conversation order is not required.
Security: workspace/channel access control lists, encryption in transit and at rest, and access-checked file links are in scope.

Clarifying Questions to Ask

What is the read/write ratio, and how large is the largest channel we must support (thousands vs. tens of thousands of members)?
Is per-conversation ordering sufficient, or does any feature require a global order across conversations?
Do we need end-to-end encryption (which constrains server-side search and previews), or is encryption-in-transit/at-rest enough?
What are the retention, legal-hold, and compliance (e.g., eDiscovery) requirements?
How many simultaneous devices per user must stay in sync, and how strict is read-state consistency across them?
Are there hard limits on message size, file size/type, and edit/delete windows?

What a Strong Answer Covers

These are the dimensions to assess — strong candidates reason their way to specific mechanisms; the bullets describe what to listen for, not the answers themselves.

Whether the candidate cleanly separates functional from non-functional requirements, commits to a concrete latency target, and reasons about how strong the ordering guarantee actually needs to be (per-conversation vs. global) rather than over-engineering it.
Whether they unify the three conversation types (channels, DMs, group chats) under a single abstraction instead of designing three parallel systems — and how their data model is partitioned and ordered to support that.
How they keep the write path durable before acknowledgment while still decoupling delivery, and how they make sends safe under client retries (dedup / idempotency).
Whether they pick an appropriate fanout strategy for small conversations vs. very large channels and justify the choice in terms of per-message cost as a channel approaches ~100k active members.
How they reason about offline delivery, reconnect catch-up, and multi-device read-state convergence under at-least-once, possibly out-of-order delivery.
Whether file sharing keeps large bytes out of the application tier (object storage, signed/expiring links, metadata, scanning, previews, access checks).
How they prioritize collaboration features (threads, reactions, mentions, search, presence) and where they draw eventual-consistency boundaries.
Whether the proposed APIs cover send, history (both directions), subscribe/stream, and search coherently.
How they handle scaling, multi-region, HA, security/ACLs , and observability/backpressure/abuse , and whether they name the key trade-offs rather than asserting a single "right" answer.

Follow-up Questions

How would you change the design to support end-to-end encrypted DMs, and what server-side features (search, previews, server-side notifications with message text) would you lose?
A single channel suddenly gets 100k members all typing during a live event — walk through exactly what saturates first and how your backpressure and fanout choices protect the system.
How do you guarantee a user's unread count and read markers stay correct across three devices when events are delivered at-least-once and can arrive out of order?
How would you implement message edit/delete so that history, search index, offline clients, and already-sent push notifications all converge to a consistent state?

Design a Slack-Like Messaging Platform

Quick Overview

Problem Statement

Constraints & Assumptions

Clarifying Questions to Ask

What a Strong Answer Covers

Follow-up Questions

Solution

Submit Your Answer to Earn 20XP

Design a Slack-Like Messaging Platform

Quick Overview

Problem Statement

Constraints & Assumptions

Clarifying Questions to Ask

What a Strong Answer Covers

Follow-up Questions

Solution

Submit Your Answer to Earn 20XP