Practice/Oracle/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. Users request a ride, get matched to a driver in real time, watch the car approach on a map, take the trip, and pay seamlessly in-app.

Interviewers ask this to test your ability to design 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 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 -- users request a ride, receive an upfront price and ETA, and get matched with a nearby driver
• Real-time tracking -- users track the driver's approach and trip in real time; drivers see navigation to pickup and dropoff
• Driver management -- drivers go online/offline, share live location, accept/decline requests, and navigate routes
• Payments -- users pay in-app (including tips), view trip history and receipts; both parties can rate the trip

Non-Functional

• Scalability -- support millions of concurrent drivers and riders across hundreds of cities
• Reliability -- maintain 99.9% uptime for ride requests; gracefully degrade features like live tracking rather than fail entirely
• Latency -- driver assignment within 10 seconds; location updates every 5-10 seconds with sub-second propagation to riders
• Consistency -- eventual consistency for driver locations; strong consistency for trip state transitions and payment captures

What Interviewers Focus On

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

1. Geospatial Matching and Driver Assignment

The core challenge is efficiently pairing ready orders with nearby available drivers while respecting capacity constraints. Poor matching causes long wait times and driver inefficiency.

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 (Redis with geospatial indexing) for sub-second proximity queries
• Use optimistic locking or short-lived reservations (SETNX with TTL) to prevent multiple rides from claiming the same driver
• Consider how to handle no available drivers: widen the search radius, increase incentives, or show "no drivers available"

2. Real-Time Location Streaming

Drivers continuously stream GPS coordinates while riders demand smooth map updates and accurate time estimates.

Hints to consider:

• Use a message queue (Kafka) partitioned by driver ID or geo-cell to decouple location ingest from fan-out
• Apply intelligent throttling and delta compression to reduce bandwidth while maintaining visual smoothness
• Compute ETAs by combining current traffic data, driver location, and road network distance
• Implement fallback strategies when WebSocket connections drop, such as polling with exponential backoff

3. Trip Lifecycle State Machine

Trips progress through multiple states (requested, matched, driver en route, arrived, in progress, completed) with transitions triggered by different actors.

Hints to consider:

• Model the trip lifecycle as an explicit state machine with valid transitions and compensating actions for failures
• Handle timeouts at each state: driver does not accept in 30 seconds, driver does not arrive within ETA + buffer
• Ensure idempotency for all state transitions since mobile apps may retry requests
• Design escalation paths for edge cases: driver cancellation after acceptance, rider no-show, wrong destination

4. Payment Flow and Financial Integrity

The payment lifecycle spans the entire trip with holds, captures, refunds, and payouts involving external gateways that can fail.

Hints to consider:

• Use payment holds (authorize but do not capture) at ride start, then capture the final amount on completion
• Implement idempotency keys for all payment gateway calls to prevent duplicate charges during retries
• Design compensating transactions for refunds when rides are cancelled, incomplete, or disputed
• Use a ledger service for immutable financial records to enable reconciliation and dispute resolution