Practice/Amazon/Design Uber

Design Uber

System DesignMust

Problem Statement

Design a ride-sharing service like Uber that allows users to request rides, matches them with nearby drivers, handles real-time tracking, and processes payments. The platform connects riders who need transportation with nearby drivers using personal vehicles, supporting the complete trip lifecycle from ride request to payment completion.

The core challenge is building a low-latency, geo-distributed, event-driven system that balances real-time data (driver locations), matching logic under contention, and a multi-step payment flow. Strong answers show you can decompose the product into services, choose the right data models and indexes for location queries, handle unreliable mobile networks, and reason about correctness with eventual consistency and idempotency.

Key Requirements

Functional

• Ride request and matching -- users request a ride, receive an upfront price and ETA, and get matched with a nearby available driver
• Real-time tracking -- users track the driver's approach and the trip in real time and can communicate with the driver via in-app messaging
• Driver management -- drivers go online/offline, share live location, accept or decline requests, and navigate to pickup and drop-off locations
• Payments and ratings -- users pay in-app including tips and see trip history and receipts, and both parties rate each trip

Non-Functional

• Scalability -- support millions of concurrent riders and drivers across multiple cities with peak demand during rush hours and events
• Reliability -- maintain 99.9% uptime for ride requests with graceful degradation during partial outages
• Latency -- driver matching within 10 seconds of request, location updates every 3-5 seconds with sub-second propagation, ETA calculations under 500ms
• Consistency -- strong consistency for payment captures and trip state transitions; eventual consistency acceptable for driver locations and ETAs

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Geospatial Matching and Driver Dispatch

Efficiently pairing riders with nearby available drivers while respecting capacity constraints and optimizing for pickup time. Poor matching logic causes long wait times, driver inefficiency, and bad user experiences.

Hints to consider:

• Partition the city into geographic cells (S2, H3, or geohash) to limit search radius and distribute load across shards
• Maintain driver availability in a fast in-memory store with geospatial indexing (Redis GEOADD/GEORADIUS) for sub-second proximity queries
• Use short-lived reservations or SETNX with TTL to prevent multiple rides from claiming the same driver during high contention
• Consider how surge pricing affects matching complexity and whether you assign greedily or use optimization algorithms

2. Real-Time Location Streaming

Drivers continuously stream GPS coordinates while riders demand smooth map updates and accurate time estimates, creating a high-throughput ingest problem coupled with complex ETA modeling.

Hints to consider:

• Use a message queue (Kafka) to decouple location ingest from fan-out, partitioned by driver ID or geo-cell for ordering guarantees
• Apply intelligent throttling and delta compression to reduce bandwidth while maintaining visual smoothness on rider apps
• Design fallback strategies when WebSocket connections drop, such as long polling or exponential backoff for reconnection
• Consider MQTT for mobile devices to reduce battery drain while maintaining low-latency bidirectional communication

3. Trip State Machine and Failure Handling

Trips progress through multiple states (requested, matched, driver en route, arrived, in progress, completed) with transitions triggered by different actors. State management must be idempotent and handle timeouts, cancellations, and no-shows.

Hints to consider:

• Model the trip lifecycle as an explicit state machine with valid transitions and compensating actions for each failure mode
• Handle driver declines or timeouts by automatically reassigning to the next best candidate with short TTL locks
• Define timeout policies for each state (driver not arriving, rider no-show) and implement automatic escalations
• Ensure idempotency for all state transitions since mobile apps may retry requests and multiple services react to the same events

4. Payment Flow and Financial Reconciliation

The platform must authorize funds before the trip, capture the final amount after completion, handle cancellation fees, tips, and split payouts between drivers and the platform.

Hints to consider:

• Use payment holds (authorize at ride request, capture after trip completion) to handle cancellations without double-charging
• Implement a saga pattern for the payment workflow: hold funds, complete trip, calculate fare, capture payment, initiate driver payout
• Ensure idempotency keys for all payment gateway calls to prevent duplicate charges during retries or network failures
• Design compensating transactions for partial refunds when issues arise during or after the trip

5. Surge Pricing and Demand Balancing

During peak times, the system must dynamically adjust pricing to balance rider demand with driver supply, requiring real-time aggregate computation across geographic zones.

Hints to consider:

• Compute supply/demand ratios per geo-cell using streaming aggregation over recent request and driver availability data
• Apply surge multipliers that update every few minutes based on zone-level metrics, caching results for fast price calculations
• Consider how surge pricing influences driver behavior (incentivizes movement to high-demand areas) and rider behavior (reduces frivolous requests)
• Display upfront pricing with surge transparency so riders can make informed decisions before confirming