SYSTEM DESIGN · QUESTION 110
How would you design a ride-sharing service?
On this page
I would clarify geography, matching latency, trip lifecycle, pricing, and safety requirements. Separate rider and driver APIs, maintain short-lived driver availability and location, find nearby candidates with a geospatial index, and coordinate assignment with an atomic state transition. Stream trip updates to both parties, persist the trip record, and design for GPS staleness, retries, cancellations, and regional failure.
LET'S MAKE IT SIMPLE
First, the idea in plain English
A ride service must match a rider with a nearby available driver and keep both apps updated as the trip progresses. Locations change rapidly, so the system needs fresh but temporary location state. Trip assignment must prevent two riders from booking the same driver at once.
A USEFUL COMPARISON
Picture it this way
A dispatcher keeps a live map of vehicles and assigns one to a request. The map can be slightly delayed, so the dispatcher confirms the assignment before promising it. A digital service uses geospatial search and atomic state updates for the same reason.
FOLLOW THE JOURNEY
Match nearby availability and confirm assignment atomically
Trace request matching, driver state, trip creation, and live updates.
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Both clients need consistent progress updates.
A ride request queries a geospatial availability index, candidate drivers are ranked, one assignment is atomically confirmed, and trip events update rider and driver clients.
How to read this visual
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Both clients need consistent progress updates.
UNDER THE HOOD
How it works, step by step
Track availability
Accept driver location and availability with timestamps and expiry.
Why it matters: Stale locations should not appear permanently available.
Find candidates
Query nearby drivers through a geospatial index.
Why it matters: Spatial search narrows matching work.
Claim assignment
Atomically reserve a driver and create a trip state.
Why it matters: Concurrent requests must not double-book the same driver.
Stream trip changes
Publish accepted, arrived, started, and completed events.
Why it matters: Both clients need consistent progress updates.
OUTSIDE THE TEXTBOOK
A practical example
A rider requests a pickup. The matching service finds available drivers near the pickup, checks that their location updates are recent, and sends an offer. The first valid acceptance wins through a conditional state change; other offers are withdrawn. The trip service stores each lifecycle transition for support and billing.
GO A LITTLE DEEPER
Technical details that matter
- Geohash, S2, or spatial indexes can support nearby search; cell boundaries require neighboring-cell checks.
- Location updates need rate limits, expiry, and privacy controls.
- Regional partitioning can reduce latency but makes cross-boundary matching and failover more complex.
MAKE A GOOD CHOICE
When is this useful?
- On-demand dispatch and logistics matching.
- Systems combining geospatial search with rapidly changing availability.
- Interview design involving state transitions and real-time events.
A small fleet can use database geospatial queries before adopting specialized indexes or regional matching infrastructure.
WATCH OUT FOR
Common misunderstandings
- Treating a stale GPS update as current availability.
- Using read-then-write assignment that allows double booking.
- Ignoring cancellations, no-shows, and reassignment.
REAL-WORLD TRADE-OFFS
Limitations and failure cases
- GPS accuracy and connectivity vary.
- Supply-demand imbalance affects matching quality.
- Real-time state and privacy are operationally demanding.
WHAT TO REMEMBER
Key takeaways
- 1Use expiring location state and geospatial candidate search.
- 2Confirm assignment with an atomic transition.
- 3Model trip lifecycle, cancellation, and real-time updates explicitly.
PRACTICE THE FOLLOW-UP
What might an interviewer ask next?
How do you prevent double assignment?
Use a conditional atomic reservation or compare-and-set on driver availability so only one request can claim the driver.
How do you handle stale driver locations?
Attach timestamps and expiry, exclude old positions from matching, and ask clients to refresh availability.
SAY IT OUT LOUD
How to explain this in an interview
“I would model driver availability as timestamped, expiring state and use a geospatial index to find nearby candidates. Matching must atomically reserve a driver so concurrent requests cannot double-book them. A durable trip state machine tracks lifecycle changes and streams updates to clients. I would also handle stale GPS, cancellation, privacy, and regional failover.”
Connect this question to the roadmap topic it supports.