10: Design Uber/Lyft | Systems Design Interview Questions With Ex-Google SWE

The capacity is off. Uber only did about 500M trips globally lasts year. If you’re using localization to load balance you can optimize for a population. Like NYC which only does about 600k trips a day.

You don’t need location checkins with the db on time scale, offload that to the client and only put it to the db on significant change in position.

Most modern dbs can process Haversian requests natively. If you really wanted to build your own you could work with arc seconds to find plane intersections and plot from there.

Ubers REST API code was dumped a few years back and it’s actually pretty simple. They have a lot of complexity around rate and surge 😮calculations.

They do have some proprietary routing and gps accuracy systems that I’m not aware of.

Good work.

Could anyone comment if they have been asked to compute the driver's exact route in an interview? Another great video Jordan, thanks! Looking forward to the Google Maps one

what do i do if i dont understand alotta this

Great Explanation as always.

Clear and insightful video. However, i think it's inappropriate that you doxxed my wife's house ( Kate Upton ).

For using viterbi algorithm's as well, can we avoid the cross partition computation, by having all the location pings go to the same db partition? we will be tracking path only when ride is in progress right? i.e only after trip id is created, driver and rider are matched. so we want persistant data from that point. so we start writing the location pings to db instead of just redis. and all those pings could be to the trips db, which can be partitioned by trip id (or rider id) but not geohash id.. So there is no scenario where state is stored across partition?

I did not understand why you have to jump the websocket from 1 server to another server as the driver moves. we can have driver connect always to the same websocket server and the location is pinged through this websocket server onto redis. during redis writes we make sure driver id in old geohash partition is erased(could also have ttl for handling race conditions of not getting deleted) and new location in new partition is written

Regarding the trip distribution. When the service wait 5 seconds before sending the trip to the 2nd driver.
It's gonna have to sort drivers again every 5 second and exclude the 1st driver. How does this work?

I guess it's some kind of scoring system that will push the 1st driver down the rank.

Why is the ClaimedTrips table is needed?

I think that just the Trips table with a driver_id column should do the job.