Interview Prompt
Design the ride request and driver matching system for a ride-sharing app.
Models the trip lifecycle as a state machine.
Uses geospatial indexing for nearby driver search.
Handles high-frequency driver location updates without overloading storage.
Discusses dispatch retries, idempotency, pricing, and fairness.
Step 1
Clarify functional and non-functional requirements first.
Functional Requirements
- Riders can request a ride from pickup to destination.
- Drivers send live location and availability updates.
- The system matches riders with nearby eligible drivers.
- Drivers can accept or reject offers within a short timeout.
- The system tracks trip state from requested to completed or canceled.
Non-Functional Requirements
- Driver search and dispatch should complete within a few seconds.
- Location updates should be fresh but do not require durable storage for every point.
- Trip state transitions must be consistent and auditable.
- The system should degrade gracefully when driver supply is low.
- Duplicate requests and retries must not create multiple active trips.
Scale Assumptions
- 5 million daily active riders.
- 1 million active drivers at peak.
- Drivers publish location every 3 seconds while online.
- 1 million completed trips per day.
Location updates
~333k/sec at peak
1M active drivers updating every 3 seconds. This is the dominant write path.
Trip requests
~12/sec average
1M trips per day, but peaks are much higher during commute hours.
Matching latency
<3 sec target
Includes candidate search, scoring, offer send, and driver response window.
Location retention
Short TTL hot store
Keep current driver position in memory or fast KV; archive sampled traces separately.
Step 2
Identify the key entities before picking storage.
| Entity | Fields and Relationships | Interview Notes |
|---|---|---|
| DriverLocation | driver_id, lat, lng, geohash, availability, updated_at | Stored in a low-latency geospatial index with TTL. |
| Ride | ride_id, rider_id, driver_id, pickup, destination, state, version | Durable source of truth for trip lifecycle. |
| DispatchOffer | offer_id, ride_id, driver_id, expires_at, status | Prevents conflicting acceptances and supports retries. |
| PricingQuote | quote_id, rider_id, pickup, destination, price, expires_at | Locks quoted price for a short window. |
Step 3
Define the APIs around the user flows.
| Interface | Request / Response | Contract Notes |
|---|---|---|
| POST /v1/rides | { pickup, destination, idempotencyKey } -> { rideId, status } | Idempotency prevents duplicate rides from mobile retries. |
| POST /v1/drivers/location | { lat, lng, heading, availability, timestamp } | Write to a geospatial hot store with TTL. |
| POST /v1/dispatch/{offerId}/accept | { driverId } -> { rideId, status } | Only one driver can win a ride assignment. |
| PATCH /v1/rides/{rideId}/state | { nextState, version } | Use versioning to enforce valid state transitions. |
Step 4
Trace the critical data flow step by step.
Driver location ingest
Mobile apps stream current driver location to location service, which updates a geospatial hot store and publishes availability changes.
Ride request
Ride service validates rider, quote, payment readiness, and idempotency before creating a requested ride.
Candidate search
Matching service queries nearby geohash cells, filters unavailable drivers, and scores candidates by ETA, rating, vehicle type, and fairness rules.
Dispatch
Offer service sends one or more timed offers, records responses, and atomically assigns the first valid acceptance.
Trip state
Ride state machine handles accepted, arriving, in_progress, completed, canceled, and payment settlement events.
Step 5
Convert the flow into a high-level design.
Final Design
Ride Sharing final architecture
Serving Layer
Start with clients, routing, APIs, and the main synchronous path users depend on for this problem.
State Layer
Anchor the design around the key entities: DriverLocation, Ride, DispatchOffer, PricingQuote.
Async Layer
Move slow, high-volume, or failure-prone work behind queues, workers, streams, caches, or background reconciliation.
Step 6
Deep dives interviewers are likely to probe.
Geospatial search
- Geohash or S2 cells let you query nearby drivers by expanding neighboring cells.
- Candidate search should overfetch and then score with road ETA if available.
- Very dense areas need cell splitting or limits to avoid huge candidate sets.
Dispatch consistency
- Use offer expiration so drivers are not locked forever.
- Only one acceptance should transition the ride to assigned.
- If a driver disconnects after accepting, the ride state machine should recover through cancellation or rematch.
Location freshness
- Drop stale locations with old timestamps.
- Use TTLs so offline drivers disappear automatically.
- Archive sampled location history separately for safety, fraud, or support workflows.
Step 7
Tradeoffs to explain out loud.
One driver offer at a time vs batched offers
Use When
One at a time reduces conflicts and improves driver experience.
Watch Out
Sequential offers can increase rider wait time when many drivers reject.
Geohash approximation vs exact road ETA
Use When
Use geohash for fast candidate retrieval, then ETA for final scoring.
Watch Out
Straight-line distance can be wrong around bridges, highways, and traffic.
Persist all locations vs hot current location only
Use When
Keep hot current location for matching and sample history for analytics.
Watch Out
Full retention is expensive and has privacy implications.
Avoid
Common mistakes that weaken the answer.
- Writing every driver location update to a relational database.
- Not using idempotency for ride requests.
- Allowing two drivers to accept the same ride.
- Ignoring stale location updates and offline drivers.
- Treating matching as nearest-driver only without ETA, eligibility, or fairness.
Step 8
Follow-up questions with strong answers.
How do you handle no drivers being available?
Expand search radius gradually, show realistic wait time, allow scheduled rides or notifications, and avoid creating a stuck ride without active dispatch.
How do you stop two drivers from accepting the same ride?
Use an atomic compare-and-set on ride assignment or a transactional state transition from requested to assigned with ride version checks.
How would surge pricing fit in?
A pricing service computes quotes from supply, demand, distance, time, and region. Quotes expire quickly and ride creation references a valid quote.
Step 9
What a strong answer should signal.
Geospatial design
Uses a hot geospatial store and describes nearby candidate expansion.
Correctness
Models dispatch and trip lifecycle with atomic state transitions.
Scale
Optimizes high-volume location updates separately from durable trip writes.
Product realism
Covers ETA, pricing, cancellations, fairness, stale data, and low-supply cases.
Practice this problem under interview conditions.
Read the guide, then run the prompt live with LeetSys so you can practice requirements, key entities, API design, data flow, whiteboarding, tradeoff narration, and follow-up handling.
Related Guides
Senior
News Feed
A complete system design guide for building a personalized social news feed with fanout, ranking, privacy, and timeline freshness tradeoffs.
Senior
Video Streaming
A senior-level guide to designing a YouTube-style video streaming system with uploads, transcoding, CDN delivery, metadata, search, and recommendations.
Senior
Real-Time Chat
A practical chat system design guide covering WebSockets, message ordering, delivery receipts, offline sync, group chats, and end-to-end reliability.