Design a chat application

What it is really testing

Whether you persist before you acknowledge, and how you order messages without trusting a clock.

Ask these first

Before a single box goes on the board. The answers change the design, which is the point of asking out loud.

• One-to-one only, or group chats — and how large?
• Is history kept forever, and is it searchable?
• Do we need read receipts and typing indicators?
• How long must an offline device be able to catch up?

The answer, in 4 moves

In this order. Each move earns the next one — say them out loud rather than drawing all four and narrating afterwards.

1. 1A WebSocket per connected client, and a registry of which server holds which connection.
2. 2Persist the message BEFORE acknowledging it — the ack is a durability promise.
3. 3Queue per recipient for anyone offline; drain it on reconnect.
4. 4Shard history by conversation id, so one hot group stays on one partition.

The trap

The follow-up that separates a rehearsed answer from a real one.

Order is per conversation, not global, and a timestamp is not an order — two phones disagree about the time. A per-conversation sequence number is what makes the transcript identical on every device.

Watch or read

The pieces of this answer, each covered on its own. Take them whichever way suits you, then give the whole answer without looking.