System Design Interview
Production-grade Snapchat architecture with ephemeral snaps, chat, stories, streaks, Discover-style feeds, media processing, realtime delivery, abuse prevention, and global resilience.
Start with the learner-friendly core: sending a snap, opening it once, replaying when allowed, saving in chat when permitted, and expiring metadata safely.
What was missing: Media storage, realtime delivery, and explicit snap lifecycle rules like replay, screenshot flags, and saved-in-chat behavior.
Why that's risky: Without explicit lifecycle policy, product semantics become inconsistent across devices and clients.
What gets added: API edge, snap/chat metadata service, lifecycle-policy service, inbox cache, and a TTL-aware metadata store with replay and screenshot metadata.
Trade-offs: Lifecycle rules add state complexity and more edge cases around replay race conditions.
Introduce friend-request workflows, privacy-aware social graph checks, and a separate long-lived store for Memories while moving media off the core API.
What was missing: Friend-request workflows, custom audiences, and a separate persistence path for user-saved Memories.
Why that's risky: Mixing ephemeral snaps and long-lived saved snaps in one store weakens privacy guarantees and complicates retention logic.
What gets added: Social graph API, friend graph store, upload session service, object storage, Memories store, media metadata store, CDN delivery, and media processing queue.
Trade-offs: Friend graph consistency, separate retention models, and signed URL flows add platform complexity.
Separate the request path from realtime delivery and engagement consumers like streaks and notifications.
What was missing: A durable event backbone for sending, opening, notifications, and engagement updates.
Why that's risky: Direct realtime-only delivery loses messages, creates duplicate notifications, and couples product logic too tightly to connection state.
What gets added: Messaging API, realtime gateways, chat event stream, delivery workers, inbox store, push notifications, and streak counters.
Trade-offs: Ordering, dedupe, and engagement counters add more event-driven complexity.
Move from messaging into a full media platform with fanout, ranking, publisher catalogs, engagement signals, and creator insights.
What was missing: Story viewer semantics like unique views vs repeat views, creator viewer lists, and replay-aware story analytics.
Why that's risky: Without a dedicated viewer/read model, creator insights become expensive and story view counts become inconsistent.
What gets added: Stories/Discover API, story fanout queue, ranking service, feed workers, story/discover cache, story store, viewer store, discover catalog, engagement stream, creator analytics, and sponsored-slot service.
Trade-offs: Fanout-on-write increases storage cost; ranking and sponsored-slot logic add latency and product complexity.
Add the heavy production systems behind a modern media app: abuse detection, moderation, and lens metadata processing.
What was missing: Abuse prevention, policy enforcement, experimentation controls, and media-intelligence workflows at production scale.
Why that's risky: Spam, fraud, unsafe media, and expensive AR/media processing can overwhelm trust, operations, and infrastructure long before raw scale limits are reached.
What gets added: Secure edge controls, risk store, policy engine, scan queue, safety workers, abuse detection workers, lens workers, moderation store, lens metadata store, feature flags, and review console.
Trade-offs: Moderation cost, false positives, and heavy compute for image/video understanding.
Finish with the architect-level view: regional isolation, observability, safe failover, and clear operational control planes.
What was missing: Regional isolation, operational visibility, analytics pipelines, and explicit rollout/failover controls.
Why that's risky: A single-region or poorly observed system fails catastrophically during outages, celebrity traffic spikes, bad experiments, or deploy regressions.
What gets added: Global traffic routing, three regional platforms, global event backbone, service discovery/config, replicas, warehouse, ML/batch jobs, observability, backups, and rollout control.
Trade-offs: Significant operational complexity, higher cost, and consistency challenges under failover.
Use storage lifecycle policies + periodic sweepers; enforce access tokens with expiry; delete metadata+blobs on schedule.
Keep a server-side snap lifecycle policy that evaluates message type, chat settings, open state, replay counters, and save permissions. Clients render based on policy decisions, but the source of truth stays on the server.
Memories have different retention, backup, access, and privacy guarantees than ephemeral delivery blobs. Separating them prevents accidental deletion coupling and makes encryption, restore, and legal retention behavior easier to reason about.
Model them as different edge types or stateful relationships in the social graph. This lets the same graph support request flows, access control for private stories, and delivery eligibility checks without duplicating logic across services.
Keep both a unique-view model and a repeat-view event stream. Use the viewer store to track first-seen order and creator-visible viewer lists, while analytics pipelines separately aggregate repeat views, completion rate, and dwell time.
Chat needs low-latency person-to-person delivery and receipt tracking, while stories are high-read fanout content with different caching, ranking, and expiry patterns. Splitting them keeps data models and scaling strategies clean.
Use conversation-scoped sequence numbers, idempotent client acknowledgements, and durable inbox state so reconnecting clients can request only the delta since their last confirmed cursor.
Keep chat delivery separate from streak accounting. Emit lightweight message-open or send events, update streak counters asynchronously in a fast counter store, and periodically reconcile counters into durable storage.
Discover behaves more like a publisher feed with ranking, editorial controls, regional availability, and content shelves. Stories are mostly friend-graph fanout with expiry. They share some infrastructure, but not the same product logic.
Friendship edges, blocks, best-friend signals, private story audiences, and recommendation inputs evolve independently from chat delivery. A dedicated friend graph service/store keeps access checks, social features, and privacy logic reusable across chat, stories, and Discover.
Use hybrid fanout. Precompute trays for normal users, but for high-fanout publishers use fanout-on-read or partial materialization with cached shelf fragments. Track publisher fanout cost and dynamically choose the strategy.
Use feature flags with cohort targeting, region-scoped rollouts, kill switches, and observability tied to both technical SLOs and product metrics. New lenses, ranking models, or UI changes should be gradual and reversible.
Partition the event backbone by domain and key: chat by conversation, stories by publisher/user, engagement by content/user, and abuse signals by account/device. This keeps replay targeted, consumers isolated, and hot partitions manageable.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
