Every call behind one Uber ride: create and search, rank nearby drivers, offer one at a time, claim atomically, and notify rider and driver.
Request a ride
Here’s one Uber ride, call by call. You tap request: POST /rides, with your pickup, your drop, and an idempotency key, so a double tap books only one ride.
The gateway checks your token, and asks the Ride Service to create the ride. It’s saved in PostgreSQL, marked searching: ride eight eight one.
Your phone gets an answer at once: a two oh two, searching. Nothing waits for a driver.
Meanwhile, the Ride Service asks Matching to find drivers near your pickup. Matching asks Redis GEO: six drivers, each with a location ping under ten seconds old.
It ranks them by pickup time: Virat two minutes away, Chris three, Rohit four. Then it sends Dispatch the shortlist, closest first.
Dispatch offers the ride to one driver at a time, down the driver’s live socket, with fifteen seconds to answer. Virat gets it first.
Virat declines, and his answer comes back on the same socket.
Dispatch offers Chris next. He doesn’t answer at all, so after fifteen seconds, Dispatch’s own timer expires the offer.
Third in line is Rohit. The offer reaches his phone the same way.
And this time, he accepts.
Dispatch checks the offer is still live, and claims the ride in PostgreSQL, in one transaction with a Ride Assigned event. The update only lands while the ride is still searching: one ride, one driver.
Only after the claim is Rohit told: head to pickup.
The saved event is relayed through Kafka to Notification, which pushes it down your phone’s live socket: Rohit, in a white Swift, four minutes away.
Eighteen calls, three offers, one claim, and only one driver ever gets the ride.