Uber system design: one ride request, from tap to driver

Request a ride

1. You tap request. Six drivers are moving nearby, and only one of them will get this ride.
2. A load balancer picks a healthy server, and the API gateway checks who you are.
3. The Ride Service creates the ride and saves it to PostgreSQL, marked searching.
4. Your phone gets an answer at once, a two oh two: searching. Nothing waits for a driver.
5. Meanwhile, Matching asks Redis GEO who’s nearby: six drivers, each with a location only seconds old.
6. It ranks them by pickup time: Virat is two minutes away, then Chris, then Rohit.
7. Dispatch offers the ride to one driver at a time, with fifteen seconds to answer. Virat gets it first.
8. Virat declines, and his answer comes back on the same live socket.
9. Dispatch offers Chris next. He doesn’t answer at all, so after fifteen seconds Dispatch’s timer fires, and the offer expires.
10. Third in line is Rohit. The offer reaches his phone the same way, and this time, he accepts.
11. Dispatch checks the offer is still live, and claims the ride in PostgreSQL: one ride, one driver.
12. Only after the claim is Rohit told: head to pickup.
13. The claim and a Ride Assigned event were saved together, so Kafka gets the event, and Notification tells your phone over its live socket.
14. Rohit is four minutes away. Three offers, one claim, and only one driver ever gets the ride.