Home / Blog / System Design Ride-Sharing: Interview Talk Track

System Design Ride-Sharing: Interview Talk Track

Published 2026-10-14 · Luna Interview

"Design a ride-sharing service" is a classic system design prompt because it touches real-time location data, geospatial search, matching, state machines, and payments all at once. The risk is trying to cover everything and ending up shallow everywhere. This system design ride sharing interview talk track gives you a structure and sample sentences so you can stay organized for 45 minutes.

Formats differ between companies and levels. Some interviewers want a broad architecture; others want you to go deep on one component. Ask early.

1. Clarify requirements (5 minutes)

Start by scoping out loud:

"I'll focus on the core flow: a rider requests a ride, we find a nearby driver, the driver accepts, and we track the trip until completion. I'll treat payments and pricing as separate services unless you'd like me to go deeper there."

Functional requirements

• Drivers send location updates while online
• Riders request a ride with pickup and destination
• System matches the rider with a nearby available driver
• Both parties see live trip status and driver location
• Trip history is stored

Non-functional requirements

• Low latency for matching (a few seconds)
• High write throughput for location updates
• Availability over strict consistency for location; strong consistency for trip assignment (no double-booking a driver)
• Scales across many cities

Ask: "Should I include surge pricing, ride pooling, or ETAs, or keep those out of scope?"

2. Back-of-envelope estimates (3 minutes)

Keep the numbers simple and say they're assumptions:

"Assume 1 million drivers online at peak, each sending a location every 4 seconds. That's about 250,000 writes per second—so location ingestion is the hottest path and needs to be designed separately from trip storage."

Ride requests are far fewer, maybe a few thousand per second at peak. That asymmetry shapes the whole design.

3. High-level architecture (8 minutes)

Name the components and draw the flow:

Flow sentence:

"Driver apps stream locations over a persistent connection to the location service, which updates an in-memory geo index. When a rider requests a ride, the matching service queries the index for nearby available drivers, ranks them, and offers the trip to one. On acceptance, the trip service creates a trip record and both apps get live updates."

4. Deep dive: geospatial indexing

This is usually where interviewers want depth.

"Scanning every driver is too slow, so I'll partition the map into cells. Options are geohash, a quadtree, or a hexagonal grid like H3. I'd pick a fixed cell grid such as geohash or hexagons because updates are cheap—moving a driver is just removing them from one cell and adding to another."

Talk through the query:

1. Convert pickup location to a cell
2. Look up available drivers in that cell and neighboring cells
3. Expand the ring if too few results
4. Rank by estimated time to pickup, not straight-line distance

Storage: keep the live index in memory (for example, a Redis-like store with geo commands, or a custom sharded service), sharded by region or cell. Location history goes to the event stream for analytics, not the hot index.

5. Deep dive: matching and avoiding double-booking

"The key consistency requirement is that one driver can't accept two trips. I'll make driver assignment an atomic compare-and-set on the driver's status: available to reserved. If it fails, the matcher moves to the next candidate."

Mention offer timeouts: if a driver doesn't respond within roughly 10–15 seconds, release the reservation and try the next driver.

6. Trip state machine

Spell out states:

REQUESTED → MATCHED → DRIVER_ARRIVING → IN_PROGRESS → COMPLETED (plus CANCELLED)

"Each transition is validated server-side and written to the trip database, and an event is published so notifications, billing, and analytics can react independently."

7. Scaling and reliability

• Shard by geography. Most queries are local, so city- or region-level partitioning keeps hot data together.
• Connection gateways. Persistent connections terminate on a stateless gateway layer that can scale horizontally.
• Drop stale pings. Location is ephemeral; losing one update is fine because the next arrives seconds later.
• Durable trips. Trip records use a replicated database with strong consistency for state changes.
• Hot spots. Airports and stadiums can overload one cell; split cells adaptively or replicate hot shards.

8. Tradeoffs to say out loud

9. Wrap-up (2 minutes)

"To summarize: a high-throughput location pipeline into a sharded in-memory geo index, a matching service with atomic driver reservation, and a trip service with an explicit state machine. With more time I'd go deeper on ETA computation, surge pricing, and pooling."

Soft practice note

System design rounds reward a steady, structured narrative more than a perfect diagram. If you want a calm way to rehearse this talk track aloud with a timer, Luna Interview is built for practice and prep—before the interview, not as a way around the rules during one.

Checklist

• [ ] Scope stated in the first minute
• [ ] Write-heavy location path called out with numbers
• [ ] Geo index choice explained with a tradeoff
• [ ] Double-booking prevention described
• [ ] Trip state machine listed
• [ ] Sharding by geography and hot-spot handling mentioned
• [ ] Two-sentence summary ready

Rehearse with an AI interview copilot, then browse commonly reported interview questions.