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

Senior

May 2026

Summary

System design round at Meta for a software engineer role. The problem was building a price tracking service at scale, the kind of thing that sounds straightforward until you're 20 minutes in and realizing you've said nothing concrete about deduplication or alert fanout.

Questions Asked (1)

Design a large-scale product price tracking service where users submit product URLs, view historical price data, and get notified when prices drop below a target threshold.

System DesignTechnical Trade-offsData Modeling

Author's notes

I started with URL ingestion and spent probably too long on canonicalization before the interviewer nudged me toward the crawling layer.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then design a high-level architecture covering data ingestion, storage, and notification. Dive into key components like scheduling crawls, handling price updates, and ensuring scalability and reliability.

Pro tip: Emphasize trade-offs between freshness and cost: for example, using adaptive polling intervals based on product popularity or price volatility. Also, discuss how to handle failures gracefully with retries and dead-letter queues.

1. Clarify Requirements and Scale

Ask questions to understand expected number of users, products tracked, frequency of price checks, and notification latency requirements. Estimate scale to inform design decisions.

2. High-Level Architecture

Outline main components: API for URL submission and data retrieval, scheduler for periodic crawling, crawler service, price storage, and notification service. Sketch data flow.

3. Data Modeling and Storage

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

4. Scalability and Reliability

Address how to scale crawling (distributed workers, queues), handle failures (retries, circuit breakers), and ensure timely notifications (push vs. pull, batching).

5. Trade-offs and Optimizations

Discuss trade-offs like polling frequency vs. cost, consistency vs. availability, and potential optimizations (caching, CDN, adaptive polling).

Key Points to Mention

Distributed crawling with rate limiting and politeness policies to avoid blocking
Efficient storage for time-series price data with retention policies
Notification system design: push (e.g., APNs/FCM) vs. pull, and handling at scale
Handling dynamic web content and anti-scraping measures (e.g., headless browsers, proxies)
Idempotency and deduplication of price updates
Monitoring and alerting for system health and data quality

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