Design Snapchat Stories

Problem statement

Design a Stories platform where users publish short-lived photo and video items that disappear 24 hours after posting, maintain a friend list with live presence, exchange ephemeral chat messages, and receive notifications when friends view their stories. The product must ingest media at planetary scale, transcode it into device-appropriate renditions, distribute it through a CDN, fan story pointers out to friends, record view receipts, deliver presence and chat in real time, and then delete everything on schedule without leaving reachable copies.

The distinctive property of this system is that ephemerality is a product promise, not a cleanup job. A permanent-feed architecture can treat deletion as eventual housekeeping. A Stories architecture must treat expiry as an invariant: after the TTL or view condition is satisfied, the media must become unreachable from clients, CDN edges, caches, and backups within a bounded, auditable window. Every design choice—object lifecycle policies, CDN TTLs, cache invalidation, pointer stores, receipt retention—must be evaluated against that invariant.

The second distinctive property is fan-out shape. A story published by an ordinary user reaches a few hundred friends; a story published by a celebrity or brand reaches millions. The same backend must serve both without hot-key collapse. That forces a hybrid fan-out model: push pointers to friends for ordinary creators, and serve pull-at-read for high-follower creators, merging both at read time.

Why the problem is distinctive

A chat backend can retry a message. A feed backend can re-rank. A Stories backend must simultaneously satisfy four conflicting pressures: heavy media bytes (ingress and egress), extreme read fan-out (views), strict time-bounded deletion (privacy), and real-time presence (state churn). Optimizing any one in isolation breaks another: a long CDN TTL improves hit ratio but violates expiry; aggressive push fan-out improves read latency but creates write amplification and hot keys; strong consistency on receipts would collapse under view volume.

Public operating baseline versus design assumptions

Public evidence establishes the category. Snap's 2025 investor materials report more than 450 million daily active users, and Snap has publicly reported billions of snaps created per day and tens of billions of video views at peak eras. Instagram Stories publicly reported 500 million daily active users in 2019, and WhatsApp Status reported comparable scale. These are cited company figures, not requirements for our fictional system.

For capacity planning this answer explicitly assumes 500 million DAU, 150 million concurrent at peak, 1.2 billion story items published per day, 6 billion story views per day, 20 billion ephemeral chat messages per day, and a 5x event peak. Unless a number is tied to a citation, it is a stated design assumption, target, budget, or illustrative threshold—not a claim about any company's private architecture.

The four architectural planes

1. Media plane: upload signing, ingress, transcoding, rendition packaging, object storage, CDN distribution, and lifecycle deletion.
2. Social plane: friendship graph, story pointer fan-out, feed assembly, view receipts, and notifications.
3. Real-time plane: presence heartbeats, ephemeral chat delivery, and WebSocket or push channels.
4. Expiry and governance plane: TTL enforcement, deletion orchestration, legal holds, privacy workflows, and audit evidence.

A strong interview answer keeps these planes separate, lets the real-time plane degrade without losing media availability, and never allows the expiry plane to be bypassed by a cache or a CDN edge.