September 11, 2024 6:15 PM PDT
This document outlines the design considerations and discussions related to a multi-user chat system, including system architecture, message handling, and service management.
System Design Interview - Design Uber
Multi-user Chat System Components
- Message Handling
- Send and receive messages
- Group management
- Message service is stateful
- Message will contain sender ID and receiver ID
- Message service finds receiver’s message service
- Add message queue using Kinesis
- Use receiver ID as the sharding key for message distribution
Connection Management
- Web Socket vs. Long Polling
- Web socket is preferred for better performance and reduced handshake time, allowing for live conversations and minimizing round trips.
- Long polling involves waiting for a response for a set duration before polling again.
Service Architecture
- Device Service
- First connect to the device service, which then connects to the message service.
- Group manager to handle group communications.
- Support for both group chats and 1-1 chats.
Scalability
- Connection Limits
- Each server can handle 63k connections.
- Use a hash of user ID for load balancing.
Service Discovery
- Service Communication
- App communicates with device service and message service.
- Consideration for using in-house device service vs. third-party solutions.
Sharding and Consumer Management
- Sharding Strategy
- The number of shards should match the number of message services to ensure balanced load.
- No limit on the number of shards.
Challenges and Considerations
- Uncertainty about managing web sockets and making the system stateless.
- Potential use of Zookeeper for service management.
Self Review
- Acknowledgment of lack of clarity regarding web sockets and the need for a stateless system design.