3 ms·

It does not say so in the article but I guess they have a database cluster for each city or something like that which makes sense since a user do not care about

It does not say so in the article but I guess they have a database cluster for each city or something like that which makes sense since a user do not care about Uber cars in a different city. Do they use GPS to put the Uber car in the right cluster? The users move around more but they are more static so they are centralized somehow?

throwbsidbdk 10y ago
It's gotta be the case. Probably choose trip db based on cutting map into squares or hexagons. Dump all location data from drivers and riders into it real time. Sounds like they've got batch jobs running against these databases to discover surge areas and stuff. Probably designed to only hit only 1-2 databases at a time for calculations they do a lot. This really looks like a crap design overall for a company started well in the age of nosql and stream processing.
- spacemanmatt 10y ago
  I'm going to guess your design assessment is unpopular. You may find that "old-skool" store-and-forward networks are pretty effective for slow-moving dimensions.
elcct 10y ago
Disclaimer: I have never used Uber. What if user orders Uber from one city to another? If driver is then in another city, wouldn't be nice to give him some rides in that city or when someone wants to go back to original city? What about cities that are near the border? If user would like to go shopping to another country? (Not uncommon in Europe. Long time ago I used to take local bus from Poland to Germany, do some shopping and go back)
- icebraining 10y ago
  Sounds fairly simple (which is not to say easy to implement); you keep the car tied to the database of origin for the duration of the ride (other users don't need to know about it while it's occupied), then you can migrate the car to the other DB when it's idle.
sciurus 10y ago
How the data is sharded is described in http://eng.uber.com/mezzanine-migration/ http://eng.uber.com/mezzanine-migration/

throwbsidbdk 10y ago

It's gotta be the case. Probably choose trip db based on cutting map into squares or hexagons. Dump all location data from drivers and riders into it real time. Sounds like they've got batch jobs running against these databases to discover surge areas and stuff. Probably designed to only hit only 1-2 databases at a time for calculations they do a lot. This really looks like a crap design overall for a company started well in the age of nosql and stream processing.

spacemanmatt 10y ago
I'm going to guess your design assessment is unpopular. You may find that "old-skool" store-and-forward networks are pretty effective for slow-moving dimensions.

elcct 10y ago

Disclaimer: I have never used Uber. What if user orders Uber from one city to another? If driver is then in another city, wouldn't be nice to give him some rides in that city or when someone wants to go back to original city? What about cities that are near the border? If user would like to go shopping to another country? (Not uncommon in Europe. Long time ago I used to take local bus from Poland to Germany, do some shopping and go back)

icebraining 10y ago
Sounds fairly simple (which is not to say easy to implement); you keep the car tied to the database of origin for the duration of the ride (other users don't need to know about it while it's occupied), then you can migrate the car to the other DB when it's idle.

sciurus 10y ago

How the data is sharded is described in http://eng.uber.com/mezzanine-migration/ http://eng.uber.com/mezzanine-migration/