Design a real-time Messaging System

Question

Design a real-time messaging system that handles millions of requests. Discuss trade-offs in consistency, availability, and performance.

Codemia · Accepted Answer

- **Functional Requirements:**  
  1. Support real-time messaging for users with minimal latency (under 100ms).  
  2. Allow one-on-one and group messaging features.  
  3. Provide message delivery status (sent, delivered, read).  
  4. Enable message history retrieval based on user requests.  
  5. Support media attachments (images, files) in messages.  
  6. Implement user presence indicators (online/offline status).

- **Non-Functional Requirements:**  
  1. Scalability: Handle millions of concurrent users.  
  2. High availability: 99.99% uptime.  
  3. Security: End-to-end encryption for messages, user authentication, and role-based access control.  
  4. Performance: Low latency for message delivery and retrieval.  
  5. Data durability: Messages should not be lost and should persist for a defined retention period.

- **User Base:** Assume 10 million active users.  
- **Messages per User:** Estimate an average of 100 messages sent per day per user.  
- **Total Messages per Day:** 10 million users * 100 messages = 1 billion messages/day.  
- **Messages per Second (QPS):** 1 billion messages/day / 86400 seconds = ~11,574 messages/sec.  
- **Storage Needs:** Assuming an average message size of 1KB, total storage = 1 billion messages * 1KB = ~1TB/day.  
- **Bandwidth:** If we assume 60% of messages have attachments averaging 100KB, then bandwidth = (0.6 * 1 billion messages/day * 100KB) / 86400 seconds = ~6.94 Gbps.

- **Component Diagram:**  
  1. **Client Applications (Web/Mobile)** - React.js / Flutter for front-end.  
  2. **WebSocket Server** - Node.js with Socket.IO for real-time communication.  
  3. **API Gateway** - NGINX for routing and load balancing.  
  4. **Messaging Service** - Microservice using Go for handling message logic and delivery.  
  5. **Database** - PostgreSQL for message persistence and user data.  
  6. **Caching Layer** - Redis for real-time data access (presence, message status).  
  7. **File Storage** - Amazon S3 for media attachments.  
  8. **Monitoring & Alerting** - Prometheus & Grafana for system health and performance metrics.

- **User Table:**  
  ```sql  
  CREATE TABLE users (  
      user_id SERIAL PRIMARY KEY,  
      username VARCHAR(255) UNIQUE NOT NULL,  
      password_hash VARCHAR(255) NOT NULL,  
      created_at TIMESTAMP DEFAULT NOW()  
  );  
  ```  
- **Messages Table:**  
  ```sql  
  CREATE TABLE messages (  
      message_id SERIAL PRIMARY KEY,  
      sender_id INT REFERENCES users(user_id),  
      receiver_id INT REFERENCES users(user_id),  
      group_id INT,  
      content TEXT,  
      has_attachment BOOLEAN DEFAULT FALSE,  
      attachment_url VARCHAR(255),  
      created_at TIMESTAMP DEFAULT NOW(),  
      status VARCHAR(50) DEFAULT 'sent'  
  );  
  ```  
- **Presence Table:**  
  ```sql  
  CREATE TABLE presence (  
      user_id INT REFERENCES users(user_id),  
      is_online BOOLEAN DEFAULT FALSE,  
      last_seen TIMESTAMP,  
      PRIMARY KEY (user_id)  
  );  
  ```

- **Consistency vs. Availability:**  
  - Opt for eventual consistency for message delivery to enhance availability and performance. Users may see messages delivered out of order but will eventually receive all messages.  
- **Database vs. Caching:**  
  - Use Redis for real-time data like message status and user presence to minimize database load, at the cost of potential cache staleness.  
- **Sharding Strategy:**  
  - Implement user-based sharding to distribute users and their messages across multiple database instances, improving scalability. Each shard can handle a subset of users while maintaining local data locality.  
- **Security Trade-offs:**  
  - End-to-end encryption impacts performance due to encryption/decryption overhead but is essential for user trust, while stored messages can be encrypted in the database for added security.

Design a real-time Messaging System

Supabase

What the Interviewer Expects

Key Topics to Cover

How to Approach This

Possible Follow-up Questions

Practice a Similar Problem on Codemia

Sample Answer

Requirements

Capacity Estimation

Submit Your Answer

Supabase Machine Learning Engineer Interview Guide

Related Questions

Design a high-throughput Inventory Management System

Design a low-latency Rate Limiting System

Design a fault-tolerant Payment System

Design a fault-tolerant Messaging System

Design Walmart Product Search