Rapido ride matching: system design for a bike captain request

The interview question sounds simple. You tap Book on a Rapido-style app, and a captain's phone rings within seconds. How?

First, a caveat. This is the standard interview design for a ride-hailing app, not Rapido's own system. The reel walks through it quickly. Here's the same flow with a bit more room.

Don't send it to everyone

The obvious answer is to broadcast the request to every captain. It's wrong. A hundred phones would ring for one ride.

What you want is three things. Fresh location, a fast match, and exactly one captain.

Location first, in cells

Every captain app sends a GPS ping every 4 seconds. With fifty thousand captains, that works out to twelve thousand pings every second. That's the load the first stage has to absorb.

Those pings go into a geo index. The index splits the city into cells, and one cell is roughly a kilometre. When a rider books, we don't scan every captain in the city. We look up the rider's cell.

Matching and offers

Matching checks the rider's cell and the cells around it. It only considers free captains, meaning captains with no ride right now. Nearest ones come first.

Then the offer goes out to one captain at a time, with a 10 second timeout. If there's no answer in 10 seconds, the offer moves to the next captain.

That timeout creates a problem worth thinking about. What if a late accept arrives after the offer has already moved on?

The conditional update

The first captain can still press accept after the timeout. If we blindly wrote that to the database, two captains could end up on one ride.

So the write to the ride database is a conditional update. The captain is set only if the ride is still unassigned. Whoever gets there first while the ride is open wins. The late accept finds the ride already taken, and the write does nothing.

After that, the ride moves through its states in order: requested, accepted, arrived, started, ended.

When a cell gets hot

Rain is the classic failure. Requests pile onto one cell, the geo index is overloaded, and matching slows down.

The fix is to split the big cell into smaller cells. The index is built for this, which is why the diagram labels it "split when hot".

The whole design in one line

Location lives in cells, offers go out one at a time, and the database picks one winner. If you can say why each of those three exists, you've covered the interview answer.

Next time you sketch a matching system, try answering the closing question from the reel. Do you offer to one captain or broadcast to all? Then explain what breaks in the one you didn't pick.