3 ms·

Wouldn't dividing their database per city make the system a lot simpler? Transfer between cities should be rare overall and it would limit the reliance on repli

• yazaddaruvala 10y ago
  What is a "city"? Where does it start, where does it stop? What if some rider starts in city X and ends in city Y (New York to Hoboken)? How do you elegantly handle that transaction? You would need consistent transactions across two databases. Usually its not possible, or at the least extremely inefficient, to implement transactions at the application layer - especially in a distributed system under heavy load. Also you end up with a lot more operational responsibility. If (when) nodes fail, how many nodes failed? How many instances of Casandra were effected? If there were X node failures, was there data loss to any of the effected instances? If there was data loss, how can we recover from a snapshot and replay all recent data to that instance without replaying it to others? Meanwhile, is the application layer really where you want to solve these scaling issues? What happens if a single city becomes too large to handle, do you partition again by neighborhood? If you're going to invest into anything, invest into improving the database. Maybe create a specialized database to handle your usecase more generally. Ideally, you want the application layer to only provide heuristics that the database can use to efficiently partition its data.
  • ebalit 10y ago
    I think that Uber is organized per city, at least on the business side. I'm talking about cities as used in [1]. I'm not even sure that you can do inter-city rides using Uber. 1: https://www.uber.com/cities/ https://www.uber.com/cities/