Katkat
Back

Design a Slack-like real-time messaging system

OpenAISoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

This problem tests your ability to design a distributed, low-latency messaging system that handles concurrent message delivery, persistence, and synchronization across multiple devices.

System Design: Real-time Messaging Architecture

Design a Slack-like messaging system that supports Direct Messages (DMs) and public channels. Your design must handle millions of concurrent users with sub-second message delivery latency.

Functional Requirements

  • Users can send messages to individuals or channels.
  • Users can see their chat history across multiple devices.
  • Users receive messages in real-time if they are online.

Non-Functional Requirements

  • Reliability: Messages must not be lost once acknowledged.
  • Scalability: The system must handle high traffic volume during peak hours.
  • Ordering: Messages within a conversation thread must maintain chronological order.
  • Latency: Message delivery should be near-instantaneous for active users.

Deliverables

  1. API Design: Define the primary endpoints for sending/fetching messages and handling real-time connections.
  2. Data Model: Propose a database schema (relational or NoSQL) for users, channels, and messages.
  3. High-level Architecture: Explain how you will handle real-time delivery (e.g., WebSockets, polling) and ensure messages reach all connected devices for a specific user.
  4. Scalability Strategy: Discuss how to partition messages for large channels and how to optimize for 'hot' conversations.

Hints

Hint 1

Consider using a message queue or a pub-sub pattern to decouple the ingestion of messages from the delivery and persistence layers.

Hint 2

Think about how to handle the 'state' of a user (e.g., online/offline status) and how to manage persistent connections using a gateway service.

Hint 3

Evaluate the trade-offs between using a SQL database for strong consistency in message history versus a wide-column NoSQL store for high-throughput write operations.

Follow-up questions

  • How would you implement the 'read receipt' or 'typing indicator' feature without overloading the system with traffic?
  • How would you handle the challenge of a user joining a large channel with millions of existing messages?
  • If the message service encounters a regional outage, how would you design for data consistency and prevent message duplication upon service recovery?