Katkat
Back

Design a Discord-Style Communication Platform

OnepaySoftware Engineer · Technical Screen
EasySoftware EngineerTechnical ScreenSystem Design

Last updated

This problem tests your ability to design a scalable real-time messaging architecture, focusing on handling message persistence, state synchronization for offline clients, and channel-based message distribution.

Design a Discord-Style Messaging Platform

Design the backend infrastructure for a communication platform that supports servers (organizations), channels, and direct messaging. The system must provide real-time message delivery and durable message history.

Functional Requirements

  1. Users can join multiple servers and access channels within those servers.
  2. Users can send and receive messages in real-time.
  3. Clients must be able to retrieve historical messages when joining a channel or after reconnecting.
  4. Messages within a channel must be strictly ordered.

Non-Functional Requirements

  1. Low-latency delivery of messages.
  2. High availability of the messaging service.
  3. Scalability to support millions of concurrent users.

Scope of Response

  • API Design: Define the necessary API endpoints (REST or WebSocket interactions).
  • Data Model: Propose a database schema for users, servers, channels, and messages.
  • Architecture: Explain how messages are routed to online users and stored for later retrieval.
  • Message Ordering: Describe how you ensure consistent message ordering in a distributed environment.

Constraints

  • Assume a global user base with varying network stability.
  • Prioritize message durability.

Example Workflow

  1. Client A sends a message to "General" channel.
  2. Server validates the session and user permissions.
  3. Server persists the message to the database.
  4. Server pushes the message to all active subscribers of the "General" channel.
  5. Client B (currently offline) receives the message upon reconnection via a synchronization protocol.

Hints

Hint 1

Consider using WebSockets or a similar persistent connection protocol for real-time delivery and a message queue for decoupling persistence from delivery.

Hint 2

For message ordering, use a monotonically increasing ID (like Snowflake IDs) rather than relying solely on server timestamps.

Hint 3

Think about using a fan-out approach for active users in a channel while using a pull-based model for users who have been disconnected for a long duration.

Follow-up questions

  • How would you handle the 'hot channel' problem, where a single channel has thousands of concurrent users sending messages simultaneously?
  • How would you implement read receipts or presence indicators (online/offline status) efficiently at scale?
  • If you needed to implement end-to-end encryption, how would this impact your ability to store message history or perform server-side searches?