Design Sent, Delivered and Read Receipts for a Mobile Messaging App

Design the message-status feature of a large mobile messaging app. When someone sends a message, their screen shows its progress: accepted by the server, delivered to the recipient's device, and read by the recipient. Status should update within moments when both people are online, and catch up correctly when either of them has been offline. Take this as the standard scope unless the interviewer changes it: - The core chat system already exists: clients hold persistent connections to chat servers, and messages are stored until the recipient's device has received them. Your job is the status (receipt) flow built on top of it. - One-to-one chats must be fully covered; group chats come in once the one-to-one design is settled. - The app has a very large user base, so status events are among the highest-volume traffic in the whole system. ```hint Follow the status home Trace one message to the recipient's phone, then ask how the news that it arrived, and later that it was read, travels back to the sender, including when the sender is offline. ``` ```hint Count before you store Compare the number of status events a busy group chat produces with the number of messages in it, and ask which of those events the sender actually needs one by one. ``` ### Constraints and Clarifications - No traffic figures come with the prompt; state your own assumptions. - Status only moves forward: a message shown as read must never fall back to delivered. - Treat privacy settings, multi-device behaviour and encryption as open questions to raise, not as decided policy. ### Clarifying Questions - In group chats, does the sender see per-member status, only an aggregate such as "read by everyone", or both? - Can users switch read receipts off, and if they do, are other people's receipts hidden from them too? - Can one account be signed in on several devices, and does reading on any of them count as read? - Are messages end-to-end encrypted, which limits what the server can inspect? - How quickly must status reach a sender who comes back online after a long time away? - What scale should we design for? ### What a Strong Answer Covers - A clear status lifecycle and a rule that keeps it monotonic - The end-to-end flow of status events from the recipient's device to the sender, with each side online or offline - What the server stores about status, for how long, and why - Volume control: batching, cumulative "read up to here" markers, and group fan-out - Duplicates, reordering and retries handled with idempotent updates, plus consistency across one user's devices - Privacy and encryption implications raised as questions and reflected in the design ### Follow-up Questions - In a group of several hundred members, how do you show "read by everyone" without flooding the sender's device? - The sender has the app open on a phone and a laptop. How do both end up showing the same status? - A user turns read receipts off. What exactly changes on the wire and in storage? - How would you detect that receipts have quietly stopped arriving for some users after a release?