Design Disappearing Direct Messages
Company: Grammarly
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Technical Screen
Design direct messages that disappear after they are viewed. Cover send, delivery, multi-device reads, deletion timing, offline clients, notifications, retries, abuse controls, and the limits of what deletion can guarantee.
### Constraints & Assumptions
- A recipient may have several devices and may be offline when the message is sent.
- Networks retry requests and can deliver events more than once.
- The product should not promise removal from screenshots or compromised clients.
- Exact traffic and retention figures should be clarified rather than invented.
### Clarifying Questions to Ask
- Does opening on one device delete the message for every recipient device?
- Is disappearance triggered by delivery, first open, or a timer after open?
- Must the service retain encrypted audit material for abuse or legal workflows?
### What a Strong Answer Covers
- A message state machine with idempotent send, delivery, view, expiry, and tombstone transitions.
- Per-recipient or per-device read semantics and conflict resolution.
- Storage, encryption, fan-out, push notifications, and cache behavior.
- Deletion workers, backups and logs, offline reconciliation, and honest client-side limitations.
- Authorization, replay protection, abuse reporting, metrics, and failure recovery.
### Follow-up Questions
- How would you handle two devices opening the same message concurrently?
- What should a push notification contain before the message is opened?
- How would the design change for a disappearing group message?
Overview: Design direct messages that disappear after viewing across multiple devices and unreliable networks. Define the deletion trigger and authoritative state, then address offline delivery, retries, notifications, abuse workflows, encryption, and honest limits such as screenshots.