Design ride-hailing and price alert systems

During a system design interview, you are asked two related but separate design questions. Treat each as an independent end-to-end design; you will be evaluated on architecture, data modeling, and how you reason about scale, consistency, and failure.

Constraints & Assumptions

These apply to both parts unless a part states otherwise:

• Scale: Millions of monthly active users; design for horizontal growth, not a fixed peak.
• Multi-region: Users and data span multiple geographic regions.
• Mobile-first clients: HTTPS for request/response; long-lived connections (WebSocket / gRPC stream / MQTT) available when the app is foregrounded.
• Latency targets: Part 1 driver-matching results $p95 < 200\text{–}300,\text{ms}$ after a ride request; Part 2 alerts delivered within a few minutes of a qualifying price change.
• Availability: Target high availability (assume $\geq 99.9%$) with graceful degradation rather than hard outages.
• Money is special: Financial state (fares, charges) requires strong consistency; locations, ETAs, and price freshness can tolerate eventual consistency.

Clarifying Questions to Ask

Scope the whole problem before designing either part:

• Is this a single global deployment, or independent per-region stacks with a thin global layer (auth, payments)?
• What are the read/write ratios and absolute throughput targets (e.g., location updates/sec in Part 1, price refreshes/sec in Part 2)?
• For Part 1, can drivers serve multiple regions, and do we control the routing/ETA/map provider or integrate a third party?
• For Part 2, do we crawl sites ourselves, use partner APIs/feeds, or both — and what are the politeness/rate constraints?
• What notification channels are in scope (push, email, SMS, in-app)?
• What are the data-retention and analytics requirements (how long to keep trips / price history)?

Part 1: Design a ride-hailing service (similar to Uber)

Design the backend for a global, mobile-first ride-hailing platform that connects riders and drivers. The system must support:

• Real-time location updates from drivers (and riders) on the order of every few seconds.
• Matching a rider to nearby eligible drivers with low latency (the $p95 < 200\text{–}300,\text{ms}$ target above).
• Trip lifecycle management: request, accept, start, end, cancel.
• Basic surge pricing driven by local supply and demand.
• Durable persistence of trip and user data for billing and analytics.
• High availability and fault tolerance across regions.

Outline the high-level architecture, the key services and their data models, and how you would handle scalability, consistency, and fault tolerance. In particular, address: (a) how you store and index geo-locations for efficient nearby-driver queries, (b) how you keep driver locations fresh, and (c) how riders receive timely updates (driver ETA, trip status).

What This Part Should Cover

• Service decomposition with the right datastore per concern: transactional store (e.g., an RDBMS) for trips/users/payments; in-memory/geo-indexed store for live locations; an event bus connecting them.
• Geo-indexing & nearest-driver search: a concrete spatial scheme (geohash or S2), cell-based candidate gathering with ring expansion, and post-filtering by availability/car-type/rating before ranking by ETA/distance.
• Dispatch correctness: avoiding double-assignment (reservation/locking), accept timeouts with retry/widen-radius, and idempotent trip creation under mobile retries.
• Scale & fault tolerance: geographic partitioning, sharding the location and trip planes, multi-AZ deployment, and explicit CAP trade-offs (strong consistency for money, availability for locations/ETAs/surge).

Part 2: Design a price tracking and alerting system

Design a backend that lets users watch product prices and receive alerts when conditions are met. It must support:

• Users registering products to watch (by URL or product ID).
• Users defining alert rules — e.g., "notify me when price drops below $X" or "notify me when the discount is at least $Y%$."
• Periodic or near-real-time ingestion of current prices from external sources.
• Storing per-product price history.
• Sending notifications (email/push/SMS) when alert conditions are satisfied.
• Operating at scale for millions of tracked products and many more alert rules.

Describe the overall architecture, major components, data storage choices, and how you would handle: (a) efficiently crawling/ingesting prices without overloading external sites, (b) evaluating alert rules at scale with reasonable latency and cost, and (c) delivering reliable, de-duplicated notifications.

What This Part Should Cover

• Staged, queue-decoupled pipeline: ingestion → normalization/history → rule evaluation → notification, each independently scalable with backpressure.
• Polite, prioritized ingestion: per-product refresh frequency (popular = more often), partner APIs/feeds where available, robots.txt/rate-limit respect.
• Storage choices that fit access patterns: relational/KV for products and rules; a time-series/wide-column store for append-heavy price history; rules indexed by product_id.
• Rule evaluation at scale: sharding rules by product, in-memory/cached rule sets, correct handling of absolute-threshold vs percent-drop (baseline) rules.
• Idempotent, de-duplicated, rate-limited notifications with retry/dead-letter handling.