Design ride-hailing and price alert systems
Overview
This question evaluates a candidate's competency in large-scale system design, including distributed architecture, real-time data processing, geo-spatial indexing and low-latency matching for ride-hailing, plus scalable ingestion, time-series storage, rule evaluation, and reliable notification pipelines for price-tracking, within the System Design domain. It is commonly asked to assess architectural trade-offs around scalability, consistency, availability, fault tolerance and operational concerns, testing practical application of architectural patterns alongside conceptual understanding of data modeling and real-time constraints.
During a system design interview, you are asked two related but separate questions:
Part 1: Design a ride-hailing service (similar to Uber)
Design the backend system for a global, mobile-first ride-hailing platform that connects riders and drivers. The system should support:
- Millions of monthly active users across multiple regions.
- Real-time location updates from drivers and riders (for example, every few seconds).
- Matching riders to nearby drivers with low latency (p95 < 200–300 ms for match results after a request).
- Trip lifecycle management: request, accept, start, end, cancel.
- Basic surge pricing support based on local supply and demand.
- Persistence of trip and user data for analytics and billing.
- High availability and fault tolerance.
Outline the high-level architecture, key services and data models, and how you would handle scalability, consistency, and fault tolerance.
Call out how you would:
- Store and index geo-locations for efficient nearby-driver queries.
- Keep driver locations reasonably fresh.
- Ensure riders receive timely updates (driver ETA, trip status).
Part 2: Design a price tracking and alerting system
Design a backend system that allows users to track prices of products (for example, items from e-commerce sites) and receive alerts when prices meet certain conditions. The system should support:
- Users registering products (by URL or product ID) they want to watch.
- Users specifying alert rules (for example, "notify me when price drops below $X" or "notify me when discount is at least Y%").
- Periodic or near-real-time ingestion of current product prices from external sources.
- Storing price history for each product.
- Sending notifications (for example, email or push) when alert conditions are satisfied.
- Operating at scale for millions of tracked products and alert rules.
Describe the overall architecture, major components, data storage choices, and how you would handle:
- Efficiently crawling or ingesting prices.
- Evaluating alert rules at scale with reasonable latency and cost.
- Ensuring reliable, de-duplicated notifications to users.
Solution
Login required