Design a large-scale Chat Platform

Question

Design a low-latency chat system that handles millions of requests. Discuss trade-offs in consistency, availability, and performance.

Codemia · Accepted Answer

### Functional Requirements
1. **Real-time Messaging**: Users can send and receive messages instantly.
2. **Group Chats**: Support for multiple users in a single chat thread.
3. **Message History**: Users can view past messages in a chat.
4. **User Presence**: Show online/offline status of users.
5. **Notifications**: Push notifications for new messages.

### Non-Functional Requirements
1. **Low Latency**: Messages should be delivered within 100ms.
2. **Scalability**: Support millions of concurrent users.
3. **High Availability**: 99.99% uptime to ensure continuous service.
4. **Data Consistency**: At least once delivery guarantee for messages.
5. **Security**: End-to-end encryption for messages.

### Estimation of Scale
- **User Base**: Assume 10 million active users.
- **Messages per User**: Each user sends an average of 10 messages per day.
- **Total Messages per Day**: 10 million users * 10 messages = 100 million messages.
- **Messages per Second (QPS)**: 100 million messages / 86400 seconds = ~1157 messages/second.
- **Storage Requirements**: If each message is 1KB, daily storage = 100 million KB = ~95.4 GB/day, or 34.8 TB/year.

### Component Diagram
1. **Client Application**: Web and mobile clients using React and React Native.
2. **API Gateway**: NGINX for load balancing requests.
3. **Message Service**: Node.js microservices for handling message sending and receiving.
4. **Database**: MongoDB for storing message history with sharding.
5. **Caching Layer**: Redis for caching frequently accessed messages and user presence.
6. **Notification Service**: FCM for push notifications.
7. **Message Queue**: Apache Kafka for handling message delivery asynchronously.

### Schema Design
- **User Collection**: { userId: String, username: String, onlineStatus: Boolean, lastActive: Date }
- **Message Collection**: { messageId: String, senderId: String, receiverId: String, groupId: String, content: String, timestamp: Date }
- **Group Collection**: { groupId: String, members: [String], groupName: String }

### Access Patterns
- Retrieve user presence and message history by userId.
- Fetch messages by groupId or userId for direct messages.

### Architectural Decisions
1. **Consistency vs Availability**: Opt for eventual consistency for message delivery to ensure high availability during peak loads.
2. **Caching Strategy**: Use Redis for caching recent messages to reduce database load, but trade off potential staleness of data.
3. **Database Sharding**: Shard the MongoDB database by userId to distribute load but increase complexity in querying across shards.
4. **Message Delivery Guarantees**: At least once delivery guarantees may lead to duplicate messages, requiring logic on the client-side to handle duplicates.

Design a large-scale Chat Platform

Goldman Sachs

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

Functional Requirements

Capacity Estimation

Estimation of Scale

Submit Your Answer

Goldman Sachs Software 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