Design an Instant Messenger With Sending, Delivered and Read Statuses

Design the backend of an instant messaging app. Besides sending and receiving messages, the app must show the sender the status of every message they send: **sending**, **delivered** (the recipient has received it) and **read** (the recipient has read it). The report gives only this requirement, so scale, group chats and the other requirements are open: settle them with the interviewer before designing. ```hint Who learns each status first For each of the three statuses, ask which component is the first to know that a message has reached it, and how that fact travels back to the sender. ``` ```hint Offline and many devices Think about what happens to a status change when the sender is offline at the moment it occurs, or is signed in on several devices. ``` ### Clarifying Questions - One-to-one chats only, or group chats too? In a group, does "delivered" or "read" mean one member, every member, or a per-member list? - How many daily active users and messages per day, and how many users are connected at peak? - Can a user be signed in on several devices, and should reading a message on one device update the others? - Does "delivered" mean that the server has stored the message or that the recipient's device has it? Should a message stored on the server but not yet on an offline recipient's device show its own status? - Can users turn read receipts off? - How long is message history kept, and are messages end-to-end encrypted? ### What a Strong Answer Covers - Requirements and scale estimates agreed before the design, with each status defined precisely and statuses that never move backwards - Persistent connections from devices, and how the backend finds the connection of a given user's devices - A send path that stores a message durably before acknowledging it, with idempotent retries and one consistent order per conversation - A delivery and read-receipt path from the recipient's device back to all of the sender's devices, including offline users and push notifications - A storage model for messages and receipt state that does not explode in group chats - Failure handling, scaling of the connection tier, and monitoring of delivery latency ### Follow-up Questions - In a large group, how do you store and show read status without writing one row per member for every message? - A user reads a conversation on their phone while their laptop is offline. How does the laptop catch up? - The recipient's device goes offline right after receiving a message but before acknowledging it. What does the sender see, and what happens when the device reconnects? - How would delivery and read statuses work if messages were end-to-end encrypted?