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

SeniorPrefer not to say

Jul 2026

Summary

System design round at Meta, one question about building a price tracking service. Pretty open-ended and I spent way too long on the data model before realizing they wanted to talk about scale.

Questions Asked (1)

Design a price tracking service similar to CamelCamelCamel, where users can set price drop alerts for products and the system periodically fetches prices from external sources at scale.

System DesignTechnical Trade-offsData Modeling

Author's notes

I went deep on the alerting pipeline first, which felt right, but then kind of fumbled when they pushed on how I'd handle millions of tracked products without hammering external sources.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying functional and non-functional requirements, then estimate scale (e.g., number of products, users, fetch frequency). Design a high-level architecture with separate components for crawling, price storage, alert evaluation, and notification, and dive deep into data modeling and trade-offs for scalability and reliability.

Pro tip: Emphasize decoupling the crawling and alerting pipelines with queues to handle failures and spikes, and discuss how to avoid duplicate alerts and ensure timely notifications. Show awareness of cost and efficiency by batching fetches and using incremental updates.

1. Clarify Requirements and Scale

Ask questions to understand the scope: number of products, users, alert types, acceptable latency, and external source constraints. Estimate scale to inform design decisions.

2. High-Level Architecture

Outline main components: product catalog, crawler/scheduler, price storage, alert service, notification service, and user management. Explain data flow from fetching to alerting.

3. Data Modeling and Storage

Design schemas for products, price history, user alerts, and notifications. Choose appropriate databases (e.g., time-series for prices, relational for users) and discuss indexing and partitioning.

4. Scalability and Reliability

Discuss how to scale crawling (distributed workers, rate limiting), handle failures (retries, dead-letter queues), and ensure alert delivery (idempotency, deduplication).

5. Trade-offs and Optimizations

Compare trade-offs like push vs. pull for alerts, frequency of crawling vs. cost, and consistency vs. availability. Suggest optimizations like caching and batching.

Key Points to Mention

Partitioning and sharding strategies for price data and user alerts to handle scale.
Using a message queue (e.g., Kafka) to decouple crawling from alert evaluation and enable asynchronous processing.
Idempotent alert processing and deduplication to prevent multiple notifications for the same price drop.
Rate limiting and respectful crawling of external sources to avoid being blocked.
Data retention policies for price history and efficient querying for alert conditions.
Monitoring and alerting on system health, such as crawler success rates and alert latency.

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