How a cab app finds your ride

Behind that one tap, the app has to answer three questions, very fast:

1. Where is every driver right now? Each driver's phone sends a GPS ping every few seconds: where it is, which way it's facing, and whether the driver is free.
2. Which free drivers are near you? Not everyone in the city, just the few who could reach you soon.
3. Which one should get your ride, and will they take it? Rank them, then ask them one at a time.

That pairing of each rider with a suitable driver is called matching. Let's take the three questions in turn.

Knowing where everyone is

A big city might have 40,000 drivers online at once. If each phone pings every 4 seconds, the app receives about 10,000 position updates a second from one city alone. Each update replaces the one before it: nobody needs to know where Ravi was 20 seconds ago to book a cab now. So the app keeps just the latest position of each driver, in the computer's fast working memory, RAM, rather than writing every ping to a database on disk. Reading from memory takes well under a millisecond.

Finding who is near

Here's the clever part. Even in memory, checking all 40,000 drivers for every booking would be wasteful, and in busy evenings thousands of bookings arrive each minute. So the map is cut into small tiles called map cells, each perhaps a kilometre across, and every driver is filed under the cell they're in. When a ping shows a driver has crossed into a new cell, the app moves them to that cell's list.

To find drivers near you, the app looks only in your cell and the ring of cells around it:

That filing system is a geospatial index. It works like a library sorting books by shelf: to find a cookbook, you go to the cookery shelf instead of reading every spine in the building. "Who is near me?" becomes "who is in these seven cells?", which might mean looking at 15 drivers instead of 40,000.

If those cells turn up nobody free, the app widens the search to the next ring out, and then the next. That's one reason "Finding you a driver" takes longer late at night or in quiet suburbs.

Picking one and asking

The drivers in those cells are a shortlist, not an answer. Some are carrying passengers. Some drive the wrong kind of vehicle (you asked for an auto, they have a sedan). And the ones closest on the map aren't always closest by road. So the app filters the list, asks a routing engine for each remaining driver's real driving time to you, and ranks them mostly by that.

Then it offers the ride to the top driver. The driver sees the pickup point and has a few seconds to accept. Only one driver is asked at a time, so that two drivers don't both turn up for you. If the driver accepts, both phones are told at once: the rider gets the driver's name and car, the driver gets directions to the pickup.

From then on, the driver's pings are passed straight to your phone, so you can watch the car approach. That's why the app feels live: the same pings that let it find Ravi now show you where Ravi is.

The simple version works on a quiet day. These are the situations that make it hard, and how the system handles each one.

"Design Uber" or "design a ride-hailing app" is one of the most common system design questions. It's popular because it mixes a huge stream of small, fast-changing data (driver positions) with careful, must-not-fail data (bookings and payments), and the interviewer wants to see whether you treat them differently.

A strong answer covers:

• a quick back-of-the-envelope load: 4 lakh online drivers pinging every 4 seconds is about 1 lakh writes a second, each replacing the last;
• driver positions in an in-memory store, filed by map cell, with old entries expiring;
• searching the rider's cell and its neighbours, widening if nobody is free;
• ranking a short list by real ETA from a routing engine, not straight-line distance;
• one offer at a time, with a timeout and a hold that only one booking can win;
• the booking as a state machine, stored in a durable database;
• live updates to the rider over an open connection, plus push notifications.

Follow-up: "How would you split the location store across many machines?" By geography, since almost every search is local: each city or region, and within it groups of cells, lives on its own machines, with extra capacity for busy cells like airports.

Follow-up: "What if the matching server crashes while a driver is held?" The hold has an expiry, so it releases itself after a few seconds; the booking's state is saved, so another server picks it up and carries on matching.

Follow-up: "How do you stop one driver being assigned to two riders?" Claim the driver in a single step that only succeeds if their status is still "free"; the second claim fails and that booking moves to its next candidate.