Design a Chat System — Cheat Sheet

A chat system must deliver messages in real time, maintain message order, support presence indicators, and handle millions of concurrent connections. The challenge is coordinating a persistent bidirectional connection layer with a durable, ordered message store.

• ✓1:1 messaging — send and receive messages between two users in real time
• ✓Group messaging — support groups of up to 500 members
• ✓Message persistence — users can scroll back through full history
• ✓Online/offline presence — show whether a contact is currently online
• ✓Read receipts — single tick (sent), double tick (delivered), blue tick (read)
• ✓Media sharing — images, videos, and files (stretch goal)

• ✓Messages / day: 50B ≈ 580,000 / sec
• ✓DAU: 500M users
• ✓Concurrent connections: ~50M (10% of DAU active at once)
• ✓Storage per message: ~100 bytes (text) + metadata
• ✓Storage / day: 50B × 100B = 5 TB / day
• ✓Storage (5 years): ~9 PB (with compression and tiering)

• ✓Client — Mobile or web client maintains a persistent WebSocket connection to a Chat Server. Falls back to long-polling for environments that block WebSockets.
• ✓Chat Server (WebSocket Nodes) — Stateful servers that hold open WebSocket connections. When a message arrives, it is written to Kafka and the server attempts immediate delivery to any online recipient connected to the same node. Horizontally scaled — each node handles ~100K concurrent connections.
• ✓Message Service — Persists messages to the Message Store. Assigns a monotonically increasing sequence ID per conversation. Publishes the message to Kafka for fan-out to recipient chat servers.
• ✓Message Queue (Kafka) — Decouples message ingestion from delivery. Each conversation maps to a Kafka partition — guaranteeing message ordering per conversation. Chat servers consume from Kafka to deliver messages to connected recipients.
• ✓Message Store (Cassandra) — Stores messages partitioned by conversation_id, ordered by sequence_id DESC. Cassandra's wide-column model is ideal: the hot read path is "last N messages in conversation X" — a single partition scan.
• ✓Presence Service — Tracks online/offline status. Clients send a heartbeat every 5 seconds. Status is stored in Redis with a 10-second TTL — if the heartbeat stops, the key expires and the user is considered offline. Presence updates are broadcast to interested parties via a pub/sub channel.

• ✓WebSocket vs long-polling → WebSocket: Full-duplex, low overhead, sub-100ms delivery. Long-polling adds ~1 extra HTTP round-trip per message and is more complex to scale.
• ✓Fan-out on write vs fan-out on read for groups → Hybrid: Fan-out on write is fast to read but amplifies writes 500x for large groups. Fan-out on read is cheaper to write but slower to read. Hybrid uses write for small groups, read for large ones.
• ✓Per-conversation sequence ID (Redis INCR) vs global sequence → Per-conversation (Redis INCR): A global sequence is a single-point bottleneck at 580K msg/sec. Per-conversation counters distribute the load across all active conversations.
• ✓Cassandra vs MySQL for message store → Cassandra: Messages are append-only, partitioned by conversation, and accessed by conversation + time range. Cassandra's data model and horizontal scalability match perfectly. MySQL would require painful sharding.

• ✓Clarify whether 1:1 only or group chat is in scope — group fan-out is a completely different problem.
• ✓Start with the WebSocket connection model. Interviewers expect you to know why polling does not work at this scale.
• ✓The message ordering problem (don't trust client clocks) always impresses. Bring up per-conversation Redis counters.
• ✓Mention the critical path: send → Kafka → persistence → delivery. Show you can identify what must be synchronous vs async.
• ✓Bring up offline delivery — push notifications + pull on reconnect. This shows product thinking.
• ✓For group chat, the fan-out write amplification problem is a classic deep-dive. Know the hybrid strategy.