Snapchat·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Jun 2026

Summary

Snapchat system design round focused entirely on a streaming event ingestion problem. Pretty open-ended, which I wasn't fully prepared for.

Questions Asked (1)

You have a stream of events in the form (user_id, device_id, timestamp). Design a system that ingests this stream and can answer the query: who is the current owner of a given device?

System DesignData ModelingTechnical Trade-offs

Author's notes

I started with the storage schema and probably should've asked more clarifying questions first.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements: event ordering, scale, latency, and consistency needs. Then propose a stream processing pipeline that maintains the latest device ownership by keying on device_id and using event-time processing with watermarks to handle out-of-order events. Finally, discuss storage and serving layers for low-latency queries, including trade-offs between consistency and availability.

Pro tip: Emphasize that device ownership is a last-write-wins problem, but out-of-order events require careful handling—use event timestamps and a bounded delay to ensure correctness. Also, mention that you'd validate the design with back-of-the-envelope calculations for throughput and storage.

1. Clarify Requirements

Ask about event volume, expected query latency, consistency requirements, and whether historical ownership is needed. This scopes the design and shows you think before coding.

2. Design Ingestion Pipeline

Propose a scalable message queue (e.g., Kafka) to ingest events, partitioned by device_id to ensure ordered processing per device. Discuss partitioning strategy and fault tolerance.

3. Process Stream for Ownership

Use a stream processor (e.g., Flink) to maintain the latest owner per device. Handle out-of-order events with event-time processing and watermarks, and use a state store for deduplication and late events.

4. Store and Serve Ownership Data

Write the latest ownership to a low-latency store (e.g., Redis or Cassandra) for fast queries. Consider write-through caching and read replicas for scalability.

5. Address Trade-offs and Edge Cases

Discuss consistency vs. availability (CAP), handling device transfers, and failure recovery. Mention monitoring and alerting for pipeline health.

Key Points to Mention

Event-time processing with watermarks to handle out-of-order events
Partitioning by device_id to ensure ordered processing per device
Last-write-wins semantics based on event timestamp
Use of a state store for deduplication and late event handling
Low-latency storage (e.g., Redis) for serving queries
Trade-offs between consistency and availability (CAP theorem)

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.