Grokking the System Design Interview
Vote

0% completed

​

Designing Uber backend

Every case study in this chapter follows the same seven steps from System Design Interviews: A step by step guide, and builds its design from the components in the System Design Master Template. Keep both open beside you, and try each problem yourself before reading the solution.

.....

.....

.....

Like the course? Get enrolled and start learning!
A

andreachiou88

· a year ago

For this use case, under heading #4 ("Basic System Design"), why didn't we specify a few APIs as we did for the URL shortener use case? is there a guideline for when, in an interview, you need to specify down to parameters what an API should contain?

李Li明穎Ming-Ying

李Li明穎Ming-Ying

· 3 years ago

How about Geohash which is more suitable for frequent updates? Lyft also uses it.

E

evan

· 3 years ago

I get how the problem is similar to the Yelp example, but for the scale at which we're working I don't think creating the Quad-Tree is necessary. Especially because the driver location information is only relevant "right now". There's no need to persist it for future reference. Wouldn't if be sufficient to only store the driver location in-memory using something like memcached? Even if the memcached server went down you could have replicas of it, and only the most recent location of the driver that would be put in memcached would be relevant.

C

CQ

· 4 years ago

Why do we need to use a push model to notify the user instead of the pull model?

Since the client is getting driver location updates every couple other seconds, the limitations of pull model such as most of the query result being empty and wasted bandwidth are no longer applying.

Show 1 reply
J

Junaid Effendi

· 4 years ago

With DriverLocationHT, if quad tree is updated 15 seconds from the DriverLocationHT, is this DriverLocationHT is getting updated every three seconds? don't we lose information between 3 - 15 seconds, not really worth it may be?

Show 2 replies

Reading Progress

0%