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

SeniorPrefer not to say

Jun 2026

Summary

Snapchat system design round, one big question about building a metrics and alerting platform from scratch. Pretty dense for a single session and I left feeling like I'd only half-answered it.

Questions Asked (1)

Design a metrics ingestion and storage platform that supports real-time monitoring, historical analysis, configurable alerting, and product-level analytics like DAU. Walk through the ingestion pipeline, your choice of time-series storage, rollup strategy, alert evaluation latency, and whether product metrics and infrastructure metrics should share the same pipeline and storage.

System DesignTechnical Trade-offsProduct Analytics & Metrics

Author's notes

This was basically four questions wrapped in one and I didn't pace myself well.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then design a unified ingestion pipeline that can handle both infrastructure and product metrics, but consider separate storage layers for different query patterns. Walk through the pipeline from collection to storage, rollups, alerting, and analytics, justifying trade-offs at each step.

Pro tip: Emphasize the importance of separating concerns: use a time-series database optimized for high write throughput and low-latency queries for infrastructure metrics, while leveraging a columnar store or data warehouse for product analytics to enable flexible slicing and dicing. Also, discuss how to handle late-arriving data and ensure exactly-once semantics in the pipeline.

1. Clarify Requirements and Scale

Ask about data volume, velocity, variety, query patterns, latency requirements, and retention policies. Understand the difference between infrastructure metrics (e.g., CPU, memory) and product metrics (e.g., DAU, retention).

2. Design Ingestion Pipeline

Propose a scalable ingestion layer using a message queue (e.g., Kafka) to decouple producers and consumers, handle backpressure, and enable multiple downstream consumers. Discuss data validation, enrichment, and routing.

3. Choose Storage Solutions

Select appropriate storage for each use case: a time-series database (e.g., Prometheus, InfluxDB, TimescaleDB) for real-time monitoring and alerting, and a data warehouse (e.g., BigQuery, Snowflake) or columnar store (e.g., ClickHouse) for historical analysis and product analytics.

4. Define Rollup and Retention Strategy

Explain how to pre-aggregate data at different resolutions (e.g., 1s, 1m, 1h) to balance query performance and storage cost. Discuss downsampling, retention policies, and how to handle late-arriving data.

5. Design Alerting and Analytics

Describe the alert evaluation engine: how to achieve low-latency alerting (e.g., stream processing with Flink, Kafka Streams) and avoid false positives. For product analytics, explain how to compute DAU and other metrics using batch or stream processing, and how to serve them via a query layer.

Key Points to Mention

Use of Kafka or similar for ingestion to handle high throughput and decouple components.
Trade-offs between using a single pipeline vs. separate pipelines for infrastructure and product metrics (e.g., cost, complexity, latency).
Time-series database selection criteria: write throughput, query flexibility, retention, and ecosystem (e.g., Prometheus for monitoring, ClickHouse for analytics).
Rollup strategies: pre-aggregation, downsampling, and materialized views to optimize query performance.
Alert evaluation latency: stream processing for near-real-time alerts, with windowing and state management.
Product analytics: computing DAU/MAU using approximate algorithms (e.g., HyperLogLog) and handling unique counts at scale.

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