Design a Chat System
Design a real-time messaging platform supporting 1-on-1 and group conversations. Handle message delivery, read receipts, online presence, message history, and push notifications for offline users.
You'll practice
Functional Requirements
- Start group chats
- Send/receive messages
- Send/receive data
- Access messages after being offline
Non-Functional Requirements
- Delivered with low latency (<500ms)
- Guarantee message delivery
- Billions of users, high throughput
- Messages not stored unnecessarily
- Fault-tolerant
Frequently Asked Questions
Should I use WebSockets or long polling for real-time chat?
WebSockets are preferred for chat systems because they provide true bidirectional, persistent connections with lower overhead. Long polling works as a fallback for environments where WebSockets are blocked, but it adds latency and server load. Most modern chat systems use WebSockets with long polling as a graceful fallback.
How do you handle message ordering in a distributed chat system?
Use server-assigned timestamps or sequence numbers rather than client timestamps. For group chats, a single authoritative server (or partition) per conversation ensures total ordering. Lamport timestamps or vector clocks can help with causal ordering across distributed nodes.
How do you implement read receipts at scale?
Track the last-read message ID per user per conversation. When a user reads messages, update their read pointer and fan out the update to other conversation participants. Batch and debounce read receipt updates to avoid excessive writes — users don’t need millisecond precision on read status.
How should you store chat message history?
Use a database optimized for time-series append-heavy writes, such as Cassandra or a sharded SQL database partitioned by conversation ID. Index by (conversation_id, timestamp) for efficient pagination. Keep recent messages in a cache layer (Redis) for fast access to active conversations.
Ready to design this system?