Design a Chat System
Send durable messages, reconnect devices and explain ordering and delivery receipts.
Backend and product engineers designing software behavior.
Your approach: Use diagrams, tables or prose for customer contracts, state transitions and data ownership; include APIs only to the depth the question requests.
The problem
Design private one-to-one and small-group chat with multiple devices per user. Explain message acceptance, durable history, online delivery and reconnect synchronization. State what ordering and read receipts mean when two devices send concurrently or go offline.
- Support 1 million concurrently connected users and 50,000 new messages/second at peak.
- Groups contain at most 100 users, and a device may be offline for seven days.
- Clients retry after lost acknowledgements; attachments are referenced files rather than inline message bytes.
Work within these constraints
Declare p95 acceptance-to-recipient delay for connected users in a healthy region.
Required target: ≤ 500 milliseconds
A sender must know when a message is durably accepted versus merely written to a socket.
Authorize delivery and history reads using a stated group-membership policy.
What to deliver
Messaging protocol
Define send IDs, acknowledgements, conversation ordering and receipt states.
Storage and connection routing
Show history ownership, live connections and attachment access.
Reconnect walkthrough
Trace offline catch-up, duplicates and two devices sending concurrently.
Capacity and failure
Estimate connection and message load; explain gateway loss and group fan-out.