Practice: Design Snapchat
Production-grade Snapchat architecture with ephemeral snaps, chat, stories, streaks, Discover-style feeds, media processing, realtime delivery, abuse prevention, and global resilience.
Build this system yourself on the canvas below. Add components, connect them, and run traffic simulations to see where your design holds up and where it breaks.
Functional requirements
- Users can send photo/video snaps and chat messages to friends.
- Users can open snaps, and the system tracks opened, expired, and screenshot-related metadata.
- Users can configure a snap as view-once, replay-limited, or saved-in-chat depending on product rules.
- Users can post stories that expire automatically after a fixed window.
- Users can save snaps to personal Memories without breaking default ephemeral delivery semantics.
- Users can receive real-time chat updates and offline push notifications.
- The system should support Snapchat-specific engagement features like streaks.
- The platform should support Discover-style publisher content and cached feed delivery.
- The system should support media processing, safety checks, and access-controlled media delivery.
- The platform should support friend graph semantics including privacy lists, blocking, and audience restrictions.
- Users can send, accept, reject, or block friend requests.
- Story creators can inspect story viewers, and the system tracks unique vs repeat story views.
- The system should support AR lenses/filter metadata and device-targeted lens delivery.
- The platform should support analytics and ranking signals for discovery, creator insights, and product tuning.
Non-functional requirements
- The system should support millions of daily active users with bursty write traffic during peak social events.
- Real-time message delivery should target sub-300ms end-to-end latency for online recipients under normal load.
- The system should provide strong privacy guarantees around ephemeral content expiry and controlled access.
- The architecture should isolate chat, stories, discover, and moderation workloads so one domain does not collapse the others.
- The platform should remain available during regional failures with documented RPO/RTO goals.
- The system should provide auditability, abuse controls, and safe operational rollout/rollback behavior.
- The platform should scale reads and media delivery independently from write-heavy messaging paths.
- The system should provide observability for both technical SLOs and product KPIs such as opens, streak retention, and story completion rates.
- The design should support eventual partitioning by user, conversation, publisher, or geography as single-cluster limits are reached.
