Design Uber

Reference Answer

For a full example answer with detailed architecture diagrams and deep dives, see our Design Uber guide.

Also review the Caching, Message Queues, and Databases building blocks for background on geospatial indexing, event streaming, and durable trip state management.

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.

The system must handle millions of concurrent users across multiple cities. The core challenges are maintaining a real-time index of driver locations that updates every few seconds, matching riders to nearby available drivers under contention (especially during surge periods), tracking the trip lifecycle with real-time map updates to the rider, and orchestrating a multi-step payment flow that handles holds, captures, tips, and driver payouts. Interviewers test your ability to decompose the product into services, choose the right data models 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 with an upfront price and ETA, and the system matches them with a nearby available driver
• Real-time tracking -- users see the driver approaching and can track the trip in real time on a map; drivers navigate to pickup and drop-off
• Driver management -- drivers can go online or offline, share live location, accept or decline ride requests, and view earnings
• Payments and ratings -- users pay in-app including tips, view trip history and receipts; both parties can rate the completed trip

Non-Functional

• Scalability -- support millions of concurrent riders and drivers across hundreds of cities, with 10x traffic spikes during events or rush hours
• Reliability -- 99.9% uptime for ride request and matching; trip state must survive server failures without losing in-progress rides
• Latency -- driver matching within 10 seconds of request; location updates propagated to rider within 2 seconds
• Consistency -- eventual consistency for driver locations and ETAs; 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 Driver Matching

Finding the best available driver near a rider is the defining technical challenge. Interviewers want to see how you index driver locations, search efficiently, and handle contention when multiple riders compete for the same drivers.

Hints to consider:

• Partition the city into geographic cells (using S2, H3, or geohash) and maintain driver locations in a fast in-memory store (Redis with geo commands) for sub-second proximity queries
• When a ride request arrives, search the nearest cell first, then expand to adjacent cells if no drivers are available
• Use short-lived atomic reservations (Redis SETNX with TTL) to prevent multiple ride requests from claiming the same driver simultaneously
• Implement a scoring function that balances proximity, driver acceptance rate, and estimated pickup time to select the best candidate

2. Real-Time Location Streaming

Drivers continuously stream GPS coordinates while riders expect smooth map updates. This creates a high-throughput ingest problem with strict latency requirements.

Hints to consider:

• Drivers publish location updates every 3-5 seconds via a lightweight protocol (MQTT or compressed WebSocket frames) to minimize battery and bandwidth impact
• Ingest location updates into Kafka partitioned by driver ID or geo-cell, with consumers updating the in-memory geospatial index and pushing changes to connected riders
• Apply delta compression and intelligent throttling: skip updates when the driver has not moved significantly to reduce noise
• Provide fallback mechanisms when WebSocket connections drop, such as long polling with exponential backoff for reconnection

3. Trip State Machine and Failure Handling

A ride progresses through multiple states (requested, matched, driver-en-route, arrived, in-progress, completed) with transitions triggered by different actors. State management must survive server crashes and handle timeouts.

Hints to consider:

• Model the trip lifecycle as an explicit state machine persisted in a durable database, with valid transitions and timeout policies at each stage
• If a driver does not accept within 30 seconds, automatically release the reservation and attempt the next candidate
• Use idempotent state transitions so that retries from unreliable mobile connections do not corrupt the trip state
• Publish state change events to Kafka for downstream consumers: ETA recalculation, rider notifications, analytics, and fraud detection

4. Payment Orchestration

The payment flow spans authorization, hold, capture, tip addition, and driver payout, with external gateway calls that can fail at any point.

Hints to consider:

• Authorize and hold the estimated fare when the ride is matched; capture the actual amount (potentially adjusted for route changes or surge) when the trip completes
• Use the saga pattern with compensating actions: if capture fails, retry with exponential backoff; if the gateway is down, queue the capture and process asynchronously
• Assign idempotency keys to all gateway calls so retries do not create duplicate charges
• Implement an outbox pattern: write the payment intent atomically with the trip state transition, then process the outbox entry asynchronously for guaranteed delivery

5. Handling Contention During Surge

During peak demand, many riders compete for a small pool of drivers. Interviewers want to see how you maintain fairness and performance under extreme contention.

Hints to consider:

• Shard the matching service by geographic cell so each shard handles a smaller contention domain independently
• Implement a queue-based dispatch model during surge: ride requests enter a priority queue and are served as drivers become available, rather than racing for the same driver
• Use surge pricing signals to balance supply and demand, reducing contention by throttling low-willingness riders
• Monitor matching latency and driver availability per cell in real time, dynamically expanding search radius when a cell is underserved

Suggested Approach

Step 1: Clarify Requirements

Confirm scope and constraints. Ask about the number of concurrent riders and drivers, whether the design covers a single city or multiple cities, and whether ride types (pool, shared, luxury) are in scope. Clarify whether driver matching should optimize for speed (nearest driver) or quality (best ETA considering traffic). Verify payment flow expectations: real-time capture or post-trip settlement. Establish latency targets for matching, location updates, and payment processing.

Step 2: High-Level Architecture

Sketch the core services: a Ride Service that manages ride requests and trip state machines in PostgreSQL, a Location Service that ingests driver GPS updates and maintains a real-time geospatial index in Redis, a Dispatch Service that matches riders to drivers using proximity queries and atomic reservations, a Tracking Service that pushes location updates to riders via WebSocket, a Payment Service that orchestrates authorization, capture, and payouts using the saga pattern, and a Notification Service for push alerts. Use Kafka as the event backbone connecting these services. Show two primary flows: the matching flow (ride request, geo query, driver reservation, acceptance) and the payment flow (authorization hold, trip completion, capture, payout).

Step 3: Deep Dive on Matching and Dispatch

Step 4: Address Secondary Concerns

Cover real-time tracking: after matching, the Tracking Service subscribes to the assigned driver's location stream in Kafka and pushes updates to the rider's WebSocket connection every 3-5 seconds. Discuss ETA recalculation using traffic APIs as the driver progresses. Address payment: authorization hold at match time, final capture at trip completion with the metered fare, tip addition within 24 hours as a separate charge. Cover monitoring: track matching latency per city, driver utilization rates, payment success rates, and trip cancellation reasons. Discuss disaster recovery: persist trip state in PostgreSQL with synchronous replication, use Kafka for event replay, and maintain fallback matching logic that degrades gracefully if Redis is temporarily unavailable. Mention fraud detection: flag rides with suspicious patterns (unusual route, repeated cancellations) for review.

Real Interview Quotes

"Asked about how to design Uber. How to avoid drivers getting multiple requests and how can a given ride only have one request sent."

"Design a ride sharing service. Make assumptions that you can use third-party APIs for already solved problems such as drivers near certain location coordinates."

Related Learning

• Uber -- complete reference answer with architecture diagrams for ride-sharing design
• Payment System -- saga patterns and idempotent payment orchestration
• Caching -- Redis geospatial indexes for driver location and proximity queries
• Message Queues -- Kafka for location streaming, trip events, and payment outbox processing
• Databases -- PostgreSQL for durable trip state and DynamoDB for high-throughput driver metadata

Walk through the matching algorithm in detail. When a rider requests a ride, the Dispatch Service queries the Redis geospatial index for available drivers within a 2-mile radius of the pickup point. It filters by availability status and vehicle type, ranks candidates by a score combining proximity and estimated arrival time, then attempts to reserve the top candidate using Redis SETNX with a 30-second TTL. A push notification is sent to the driver's app. If the driver accepts, the trip transitions to "matched" and the reservation is converted to an active trip assignment. If the driver declines or times out, the reservation expires and the next candidate is tried. Discuss how concurrent ride requests for the same driver are handled: the SETNX ensures only one request wins the reservation; losers immediately move to the next candidate without waiting. Address the expansion strategy: if no drivers are found within 2 miles, progressively expand to 4, then 8 miles, with each expansion adding latency that is communicated to the rider.