Design a backend system for an e-commerce price-tracking service. Users can track products from a large online retailer, view historical prices, and receive alerts when prices drop below a threshold or by a configured percentage. ### Functional Requirements - Users can add a product to track by URL or product ID. - The system periodically fetches current product prices from a retailer API or scraper, depending on the assumption you choose. - The system stores timestamped price history for each tracked product. - Users can create alerts such as "notify me below $X" or "notify me after a Y% drop." - The system sends notifications when alert conditions are met. ### Non-Functional Requirements - Support millions of users and tens of millions of tracked products. - Price freshness can vary: popular products should update more frequently than long-tail products. - The service should be highly available and cost-conscious. - It is acceptable for alerts to be delayed, but duplicate or missed alerts should be minimized. ### Constraints & Assumptions - State whether you assume an official retailer API, web scraping, or both. - Respect rate limits, legal constraints, and retailer access policies. - Price history may become very large, so storage and downsampling need to be addressed. - Product metadata and price history have different access patterns and may use different storage systems. ### Clarifying Questions to Ask - Are we tracking one retailer or many retailers? - What freshness SLA is expected for popular versus long-tail products? - Which notification channels are required for v1? - How long must raw price history be retained? - Are users allowed to create many alerts for the same product? ### What a Strong Answer Covers - High-level architecture with API, product metadata, scheduler, fetch workers, price history storage, alert evaluation, notification, and monitoring. - A data model for products, users, subscriptions, price points, alerts, and notification logs. - A scalable scheduling strategy for fetching prices based on popularity and volatility. - Idempotent ingestion and alerting to handle retries safely. - Storage tradeoffs for high-resolution history versus downsampled aggregates. - Reliability, rate limiting, observability, and cost controls. ### Follow-up Questions - How would you design the dynamic crawl scheduler? - How would you prevent duplicate notifications after retries? - How would you store years of price history cheaply? - How would the design change for multiple retailers and regions?