Loading...
Driver report locations
User request Uber, match a driver
advanced:
Driver decline, accept request
driver cancel matched request
rider cancal a request
Dricver pick up rider
driver drop off rider
Outofscope
Uber eats
High availability
reliable
500K Daily Active Drivers
Drivers QPS = 500K / 4 = 125K --> write heavy
Peek driver QPS = 375K
Rider QPS -> 500K * 5 = 2.5M riders
2.5M / 100K = 25
Update Locations(driver_id, latitude, longtitude)
Trip table
Trip_ID
Driver_ID
rider_ID
geohash
createby
Location Table
Driver_id
geohash
udpated_at
Location table -> Redis
GeoHash key
Drivers list
Driver Table
Driver_id
Driver_name
Driver metadata
Status:
For the location. use Google S2 or GeoHash transfer latitude and longitude to one String, and the most common prefix means they are closed on map
Use prefix to create a key value list
Key is the prefix of geohash
value is the driver list
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
Redis Server is Down? Replica ny Redis, master - Slave
DB sharding avoid single point failure, Geohash
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?