advanced practice · system design prompt
Realtime chat system
Design a Slack-like chat: 1:1 + channels, presence, delivery + read receipts, offline message queue. Pick the wire protocol and how messages fan out.
The mechanism
Realtime messaging is two problems wearing one name. On the server it is long-lived connections plus fan-out: WebSockets are stateful, which constrains your load balancer, and choosing per-channel versus per-user fan-out is the central design decision. On the client it is maintaining a local projection of remote state that survives disconnects and reordering — so the protocol needs message identity, a sequence number, a reconnect-and-catch-up path, and a reconciliation rule for optimistic updates the server later rejects.
Expected evidence
Connection layer + message storage + the fan-out strategy for a 10k-member channel.
Try this drill in the practice workspace →
Hints when you need them
- WebSocket connections are stateful — that constrains your load balancer.
- Fan-out on write vs on read changes everything downstream.
Watch for these mistakes
- Sticky sessions as the only fan-out plan, so one hot channel pins to one node
- No sequence number, leaving the client unable to tell a reconnect gap from an ordering swap
- Optimistic UI with no reconciliation path when the server rejects the write