Ride hailing system design

Questions to ask the interviewer

The design in short

A ride app answers one question over and over: which free cars are close to this rider? Then it hands each ride request to one of those drivers. The map question runs far more often than anything else, so it shapes the design.

Near is the hard word. A table of drivers sorted by id cannot tell you who is near a street corner. If every map view reads every driver, the work grows with the size of the fleet, not with the size of the answer. A rider only cares about a few blocks around them. Ask how the data can be laid out so a view touches only the drivers close by, and how many reads that takes.

Two kinds of traffic meet here. Riders look at the map and wait for the answer. Driver phones send where they are, and nobody waits for that. Ride requests sit in between: the rider gets "Finding your driver" at once, and the offer reaches a driver a moment later. Decide which work belongs in the reply and which can happen after it.

Things to place on the whiteboard:

• the app servers that answer map views, and how many the view rate calls for
• where driver locations are kept, and how a map view finds the ones nearby
• the path a ride request takes from the rider to a driver's phone
• what the rider sees while that path runs

Work out the reads first. Take the drivers online and the rows one read returns. Multiply by the map views a second. Compare that total with what a single database can serve, and the need for a smarter layout shows up on its own.

Keep the city in mind. The brief covers a single city. That limit keeps the map small and the numbers easy to check, so use it. Payments, prices and ratings are real parts of a ride app, but they are not this interview.

Try the layout on the GonnaCrash board and watch the map views reach the drivers, or fail to.