Katkat
Back

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

AmazonSoftware Engineer · Other
MediumSoftware EngineerOtherSystem Design

Last updated

A system design question about the sent, delivered and read indicators in a large mobile messaging app, for one-to-one and group chats. It tests how status updates travel from the recipient's device back to the sender, offline and multi-device behaviour, keeping status monotonic, and controlling the volume of status events.

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.

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?

Hints

Hint 1

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 2

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.

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?