Art of Codeartofcode
Lesson 8 of 15

44. Design Ride-Hailing with Surge Pricing (Uber / Rapido)

1
The interview prompt
2
44.1 What do you ask first?
3
44.2 How big is this, really?
4
44.3 What are the doors?
5
44.4 What do we store?
6
44.5 What does the whole system look like?
7
44.6 How are location updates handled?
8
44.7 How does matching work?
9
44.8 How does surge pricing work?
10
44.9 How does the trip state machine work?
11
44.10 What would you say in the last five minutes?
12
Score yourself
13
Variations to practise
14
Sources
15
Code lab
44. Design Ride-Hailing with Surge Pricing (Uber / Rapido)

44.7 How does matching work?

3 min read+10 XP

closest by straight line is a driver across a river with a 6-minute road ETA; a farther driver on the same side arrives in 5 minutes; candidates are ranked by ETA, offered one at a time, and assigned atomically.

Figure: rank by road time, offer one at a time, assign only once.

  1. Candidates: available, recently seen drivers in the pickup cell and its neighbours; widen the search if too few.
  2. Rank by ETA: ask the maps service for road ETAs for the top few. In the chapter's code, driver A is 0.7 km away across a river (about 6 minutes by road), and driver B is 1.2 km away on the same side (about 5 minutes): B wins.
  3. Offer one at a time with a short timeout (~10-15 seconds); if declined or ignored, offer the next.
  4. Assign atomically: "set driver's current trip = t1 only if it's empty" (Chapter 17). In the chapter's code, two riders' requests both pick driver d0 at the same moment; the first gets d0, the second falls through to d7. Nobody gets the same driver twice.
  5. No one accepts: widen the radius, raise the offer to more drivers, or tell the rider and suggest waiting.

Bigger systems also batch matching: collect requests for a second or two and solve the assignment for the whole area together, which beats greedy one-by-one matching when demand is high.

Memory code: "Nearest by road, one offer at a time, one driver per trip."