Katkat
Back

Design a One-to-One Chat System

TemporalSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

This problem tests your ability to design a distributed, low-latency, real-time messaging system, focusing on message delivery guarantees, state management, and scalability.

Problem Statement

Design a scalable one-to-one chat service similar to WhatsApp or Telegram. The system must support millions of concurrent users with sub-second message delivery latency.

Functional Requirements

  1. Users can send and receive one-to-one messages in real-time.
  2. Users can see their message history.
  3. The system should track online/offline status (presence).

Non-Functional Requirements

  1. High availability: The system should not go down if a single server fails.
  2. Low latency: Messages should be delivered nearly instantly.
  3. Ordering: Messages between two users must be delivered in the order they were sent.
  4. Scalability: The system must handle up to 10 million Daily Active Users (DAU).

Deliverables

Provide an architectural overview covering:

  • API design (e.g., endpoints for messaging and presence).
  • Data model: How to represent users, conversations, and messages in a database.
  • High-level architecture: The interaction between clients, load balancers, messaging servers, and persistent storage.
  • Handling real-time delivery: How the system routes messages to an offline recipient vs. an online recipient.
  • Trade-offs: Justify your choices regarding database selection (SQL vs. NoSQL) and message delivery guarantees (At-least-once vs. Exactly-once).

Hints

Hint 1

Consider using WebSockets for bidirectional, real-time communication between the client and the server.

Hint 2

Think about how you would partition the data to ensure that message history is retrievable even if a specific server node fails.

Hint 3

Address the 'offline' scenario by using a push notification service or a temporary message queue until the recipient reconnects.

Follow-up questions

  • How would you implement 'read receipts' (e.g., the double-check mark) without overwhelming the server with status updates?
  • If the chat system grows significantly, what strategies would you use to shard the message database while keeping conversation history performant?
  • How would you ensure end-to-end encryption while still allowing the system to index messages for search?