Katkat
Back

Design a Slack-Like Messaging System

DatabricksSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Tests your ability to architect a scalable, real-time messaging platform like Slack, focusing on connection handling, fan-out delivery, channel message ordering, and presence management.

Scenario

Design a real-time team collaboration and messaging service similar to Slack. The system must support public and private channels, direct messages (DMs), message history pagination, and user presence indicators.

Requirements

Functional Requirements

  • 1:1 and Channel Messaging: Users can send and receive text messages in real time in 1:1 direct messages and multi-user channels.
  • Message History: Users can scroll up to fetch historical messages paginated by timestamp or sequence.
  • User Presence: Users can see whether workspace members are currently online or offline.
  • Unread Badges / Read Receipts: Track read state per channel for each user.

Non-Functional Requirements

  • Low Latency: Real-time message delivery latency under 100ms within the same geographical region.
  • Message Ordering: Messages within a channel must be strictly ordered and consistent across all participants.
  • Durability & Fault Tolerance: Once acknowledged, messages must never be lost.
  • Scalability: Must handle both small group chats and massive announcement channels without service degradation.

Scale & Traffic Estimations

  • Daily Active Users (DAU): 20 million users.
  • Peak Concurrent Connections: 5 million concurrent active WebSocket connections.
  • Message Volume: 500 million messages per day (~6,000 messages/sec average, 25,000 messages/sec peak).
  • Channel Sizes: Range from 2 users (DMs) to 50,000+ users (company-wide announcement channels).
  • Average Message Size: 500 bytes of text and metadata.

What to Cover

  1. API Design: Define key client-to-server endpoints (e.g., sending messages, querying history, managing channel subscriptions).
  2. Real-Time Architecture: Design the connection layer (e.g., WebSockets vs. HTTP long-polling), gateway routing, and connection session tracking.
  3. Message Fan-Out & Pub/Sub: Explain how a message sent by one user is distributed to all online channel members, contrasting small channels with very large channels.
  4. Data Modeling & Storage: Propose database engines and schemas for users, channels, messages, and read cursors.
  5. Presence Service: Detail how client heartbeats and online/offline status updates are tracked efficiently at scale.

Hints

Hint 1

Decouple stateful connection gateways (which maintain persistent WebSockets) from stateless application and message processing services.

Hint 2

For message ordering, consider generating monotonically increasing 64-bit IDs (such as Twitter Snowflake) or channel-scoped sequence numbers to avoid distributed locking.

Hint 3

Avoid naive push fan-out for channels with tens of thousands of members; consider hybrid pull/push or batched delivery strategies to prevent gateway overload.

Follow-up questions

  • How would you redesign message delivery for massive channels (100,000+ members) to prevent the 'thundering herd' problem on the WebSocket gateway?
  • How would you architect full-text search across billions of historical messages while enforcing channel membership access control?
  • How do you handle message synchronization when a mobile client reconnects after being offline for several hours?