Katkat
Back

Design a Slack-Like Messaging Platform

CrusoeSoftware Engineer · Onsite
EasySoftware EngineerOnsiteSystem Design

Last updated

Design a real-time team messaging platform supporting channels, direct messages, message persistence, and presence tracking. The design tests your ability to model conversations, ensure reliable and ordered message delivery, and handle high-throughput fan-out.

Scenario

Design the core backend architecture for a team collaboration and chat application similar to Slack. The platform allows users within an organization to communicate in real-time through persistent public/private channels and one-on-one direct messages.

Requirements

Functional Requirements

  • Messaging: Users can send and receive text messages in real time in public channels, private channels, and 1-on-1 direct messages (DMs).
  • Message History: Users can fetch paginated message history when opening or scrolling back through a conversation.
  • Message Ordering & Idempotency: Messages within a conversation must be presented in chronological order and duplicate deliveries must be prevented.
  • Read Receipts & Presence: Basic user presence status (online, away, offline) and unread message indicators.

Non-Functional Requirements

  • Low Latency: End-to-end delivery latency under 200 ms for active users.
  • High Availability: 99.99% availability for the messaging pipeline; transient failures should not result in lost messages.
  • Durability: Once an acknowledgment is returned to the sender, the message must not be lost.

Scale & Numbers

  • Daily Active Users (DAU): 10 million.
  • Peak Messages: 50,000 messages sent per second.
  • Channels per User: Average user belongs to 50 channels; large public channels can have up to 100,000 members.
  • Storage: Retain messages for at least 5 years.

What to Cover

  1. API Design: Define the key endpoints for sending messages, fetching channel history, and subscribing to real-time events (e.g., WebSockets, HTTP).
  2. Data Model & Partitioning: Choose appropriate storage engines (SQL vs. NoSQL) and define schema designs and sharding keys for messages and conversation memberships.
  3. Real-Time Delivery & Fan-out: Describe the connection management layer and message delivery path for both small direct messages and high-occupancy channels.
  4. Ordering & Reliability: Explain how message sequencing (e.g., monotonic IDs per conversation) and client-side deduplication are guaranteed.

Hints

Hint 1

Separate the real-time push mechanism (WebSocket gateway backed by a pub/sub layer) from durable message ingestion and persistence.

Hint 2

For message ordering, consider assigning monotonically increasing IDs per channel using a distributed sequence generator or database auto-increment scoped to conversation IDs.

Hint 3

Avoid naive fan-out writes to every channel member's mailbox for large public channels; use a pull-based or pub/sub fan-out approach instead.

Follow-up questions

  • How does your architecture handle a 'thundering herd' when a popular public channel with 100,000 members receives a flurry of messages?
  • How would you integrate file attachments and media previews securely without overloading the real-time chat pipeline?
  • What strategies would you employ to handle cross-region replication while maintaining causal message ordering for distributed teams?