Design an Ephemeral "Chat & Disappear" App

Problem statement

Design an ephemeral messaging service — call it GhostChat — where texts and images vanish after being read or after a sender-chosen timer. The product must support one-to-one and small group chats, read-based and timer-based expiration, delivery and read receipts that themselves auto-delete, optional screenshot detection with sender notification, and a credible guarantee that expired content is removed from servers, caches, backups, and best-effort from recipient devices.

This is not a normal chat system with a delete button. A conventional messenger optimizes one property: messages must never be lost. An ephemeral messenger must optimize two opposing properties at once: messages must never be lost before they are read, and must be unrecoverable after they expire. The first property wants durability, replication, retries, and backups. The second wants exactly the opposite. The whole architecture is the managed tension between them.

Two expiration semantics

The problem requires both timed and read-based auto-deletion, and they behave very differently under failure.

Timed expiration (WhatsApp-style disappearing messages, Signal timers) starts a countdown when the message is delivered or first opened, and the clock is server-authoritative: it keeps running even if the recipient is offline. Read-based expiration (Snapchat-style Snaps) starts only when the recipient actually opens the content, which means the server cannot trust the client clock, must distinguish delivered from viewed, and must decide what happens when a recipient opens content while half-offline.

Both semantics share one hard rule: once expired, a message must be unservable everywhere — primary store, read replicas, caches, CDN edges, push payloads, and device-local plaintext. Deletion is not a background chore; it is a first-class product invariant with a measurable SLO.

Why the problem is distinctive

A durable chat system can retry anything. An ephemeral system cannot retry a leak. If a deletion batch is lost, the failure is invisible to users and violates the core promise silently. Therefore the deletion plane needs its own durability, its own observability, and its own failure semantics — fail-closed serving that refuses to return content whose expiry has passed, rather than fail-open serving that returns content because the deletion worker is lagging.

Public operating baseline

The category is real and large. Snap reports roughly 432 million daily active users for Snapchat, and WhatsApp publicly announced 100 billion messages per day in October 2020 across about 2 billion users. Telegram reported approaching 950 million monthly users in 2024, with self-destructing Secret Chats as a long-standing feature. Signal, the open-source reference for disappearing timers ranging from one second to four weeks, reports tens of millions of monthly users. These are company-reported public figures that establish scale plausibility; every uncited number in this answer is an explicit design assumption.

The four architectural planes

1. Delivery plane: ingestion, end-to-end encrypted transport, store-and-forward, per-recipient queues, presence, push.
2. Expiration plane: timers, read triggers, sweepers, tombstones, and the fail-closed serving gate.
3. Cryptographic plane: session ratchets, per-message content keys, wrapped keys, and crypto-shredding so expiry is effective immediately even where bytes remain.
4. Trust plane: safety scanning at the architecture level, report-hold exceptions to ephemerality, audit, and legal compliance.

A strong interview answer keeps these planes separate. The delivery plane may degrade and retry; the expiration plane must fail closed; the cryptographic plane makes deletion immediate and provable; the trust plane carves narrow, audited exceptions without silently disabling the other three.