Katkat
Back

Design Disappearing Direct Messages

GrammarlySoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Design an ephemeral direct messaging system that reliably deletes messages after viewing across multiple devices, handles offline delivery, and balances user privacy with abuse reporting.

Scenario

You are tasked with designing an ephemeral direct messaging feature for a modern communication platform. Users can send 1:1 messages that automatically self-destruct after being viewed by the recipient. The system must support users with multiple active devices, handle flaky network connections, and provide clear mechanisms for abuse reporting without compromising the core privacy promises.

Requirements

Functional Requirements

  • Ephemeral Lifecycle: Messages can be configured to disappear either immediately after reading or after a predefined timer (e.g., 5 to 60 seconds) triggered upon first view.
  • Multi-Device Sync: If a recipient views and triggers deletion on one device (e.g., mobile), the message must be marked read and deleted across all their other devices (e.g., desktop, tablet), as well as on the sender's devices.
  • Offline Delivery & Catch-Up: Devices that are offline when a message is sent or read must correctly reconcile state upon reconnecting.
  • Abuse & Reporting: Users must have a way to report malicious or abusive messages before or during the view window, even if the payload is scheduled for immediate deletion.
  • Push Notifications: The system must alert recipients of new messages without leaking sensitive message content via third-party notification services (APNs/FCM).

Non-Functional Requirements

  • Low Latency: Real-time delivery latency under 200 ms for online recipients.
  • High Availability: 99.99% availability for core messaging pipelines.
  • Strong Deletion Guarantees: Server-side payloads must be permanently expunged once read receipts are processed or maximum server retention expires.
  • Client Boundaries: Clearly identify and address the realistic limits of ephemeral security (e.g., screenshots, memory dumps, modified client software).

Scale Assumptions

  • 50 million daily active users (DAU).
  • Average of 40 messages per user per day (~2 billion messages/day; ~25,000 msgs/sec average, ~75,000 msgs/sec peak).
  • Average user has 2.5 active devices linked to their account.

Key Areas to Cover

  1. Architecture & Message Flow: High-level system components, gateway connections (e.g., WebSockets), and data flow from send to purge.
  2. State & Deletion Ownership: Clarify whether the client or the server is the authoritative source for read times and countdown triggers.
  3. Data Model & Storage: Data schemas, message status states, and database engine choice for ephemeral storage and TTL purges.
  4. Security & Edge Cases: Handling out-of-order delivery, handling network disconnects mid-countdown, and technical strategies for abuse reports.

Hints

Hint 1

Consider whether the server or the client holds the authoritative countdown timer once a message is opened, and evaluate the trade-offs between trust and latency.

Hint 2

Think about how an abuse report can verify the authenticity of a message without requiring the server to permanently retain cleartext payloads.

Hint 3

Address how an offline device receives a purge command for a message that was already viewed and expired on a user's other device.

Follow-up questions

  • How do you handle media attachments (e.g., images/audio) stored in object storage to ensure they are scrubbed reliably when the metadata expires?
  • If you incorporate End-to-End Encryption (E2EE), how does your abuse reporting pipeline verify the authenticity of a reported message without breaking user privacy?
  • How would you design the system to handle a malicious client that acknowledges receipt but intentionally ignores deletion commands?