Katkat
Back

Design a Real-Time Chat System

UberSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This question tests the ability to design a highly available and scalable real-time chat service, focusing on persistent connections, message routing, and reliable delivery mechanisms.

Problem Statement

Design a real-time messaging system (similar to WhatsApp or Messenger) that supports millions of concurrent users. The system should allow users to send and receive text messages, show delivery/read status, and support offline messaging.

Functional Requirements

  1. One-on-one private messaging.
  2. Message status (Sent, Delivered, Read).
  3. History/Sync: Users should see past messages when logging in from new devices.

Non-Functional Requirements

  1. Low latency: Messages should be delivered in near real-time (< 200ms).
  2. High availability: The system must handle hardware failures without losing messages.
  3. Scalability: Ability to handle 10 million concurrent active users.

Deliverables

  • High-level architecture diagram (described in text).
  • Selection and justification of the communication protocol (e.g., WebSockets, HTTP Long Polling).
  • Database schema design for messages and user status.
  • Strategy for handling users who are offline when a message is sent.

Considerations

  • How will you handle service discovery for stateful connections (where the user is connected)?
  • How do you guarantee message ordering and prevent duplicates in a distributed environment?
  • Describe the flow when User A sends a message to User B, and User B is offline.

Hints

Hint 1

Consider using WebSockets for bidirectional communication to minimize overhead compared to polling.

Hint 2

Use a distributed cache like Redis to store mapping of UserID to their active Connection Server instance.

Hint 3

Decouple message storage from message delivery using a message queue or persistent store (like Cassandra or DynamoDB) to handle offline buffering.

Follow-up questions

  • How would you modify this design to support group chats with thousands of participants?
  • What changes are required to ensure end-to-end encryption while still allowing the server to store messages for offline users?
  • How would you handle a 'thundering herd' problem if a popular server instance crashes and all connected clients attempt to reconnect simultaneously?