Search code examples
architectureload-balancingcomputer-science

UberEats High Level Design

I'm practising for the High Level Design Interview for a SDE 3-4.

I did this design for UberEats and I had some questions.

The functional requirements are:

  1. Get list of near restaurants
  2. Get dishes from a restaurant
  3. Depending on user location we have to calculate the near restaurants
  4. Get the order and processing it to the restaurants
  5. Payment can be done by a third party
  6. Location and work hours of the restaurant
  7. Track of order status / Notifications to users
  8. Recommendation system
  9. Integration with restaurant OMS
  10. Delivery
  11. User feedback to the restaurant

And the Non Functional are:

  1. Low Latency
  2. High Availability
  3. High Consistency
  4. 1 milion orders per day
  5. 500 thousands DAU

I put a picture of my design below.

My questions are:

I have to specify which type of communication is between the microservices?

This is a good level of detail or I have to go more deeper?

The notification service part, I don't know if it's correct I was thinking about a messageQueue and the OMS (Ordering Management System) will take care of putting order updates to the message queue.

I did some research but I'm pretty lost in this type of designs so all the help is welcome.

UberEats High Level Design

Solution
    • I'm not familiar with the Amazon method and the specific expectations they might have, regarding what you need to provide. But I can talk more generally about HLD and your two specific questions.

    General Comments on Your Diagram vs HLD

    1. I like the "architecture on a page" approach you've taken, in that you are conveying a lot of related info together - not drowning readers in a 1,000-page document.
    • One thing you can improve is the presentation/layout so that information is appropriately compartmentalized. It will make it easier to digest. Bolded headings, dividing lines, or enclosing boxes / shaded background panels, etc.

    1. Always think about the audience - what do they need to know? And your message - what are you wanting to convey. Thinking about this will help you tune both the information you include, and how you present it.

    2. Does the HLD demonstrate answers to the questions being asked?

    • E.g: the non-functionals: looking at your HLD how do you know it will be "highly available" and 1M orders a day - do you know how many that is on average per hour, minute? and that the components/technology selected can handle that in this design?

    1. The data schema looks ok for an HLD, but adding relationships (connector lines) might be useful. If it becomes too complicated (too many connections) it might not be feasible to include it on the same page as everything else.

    2. One gap you might have is (API) "[Resources][2]" ([more about them here][1]). API's especially REST-based APIs should deal with resources. You have called out a data schema (how the data is stored). The resource model need not be complex.

    • But as I say, you might not need to have one. If I was doing an HLD that included an API I probably would do one, especially if the API was going to be consumed by external 3rd parties.

    (Do) I have to specify which type of communication is between the microservices?

    1. Refer to my #2 above. The short answer is probably "yes", in terms of the HLD as a whole, but not necessarily in the context of one diagram.

    2. If you have a lot of microservices, and especially if the relationships between them is non-trivial, then you might have two diagrams: one showing all the microservices and how they relate, a second showing the different communication types.

    3. Typically communication between microservices should be relatively consistent - so you should be able to do this by dealing with communication between types of microservice, as well as any special cases if they exist.

    4. The second "diagram" could also be a table/matrix that lists the microservices and key info about them, e.g: external-facing y/n, type (service, orchestration, etc), which business domain it sits in, etc.

    This is a good level of detail or I have to go deeper?

    1. I can't speak to the Amazon expectations, but in general terms the level of detail is good - you probably wouldn't want to go deeper.

    2. Your main diagram is doing two things - some elements are described with a functional (e.g. "Rider App"), some purely technical (e.g. "Messaging queue"), most with both. I prefer the latter, just try to be as consistent as you can.

    • If I was doing this I might have a functional representation and a separate technical one because beyond a certain level of complexity it can just be too much to deal with.
    1. See if you can make the diagram more elegant; that may sound funny but a diagram that is elegant and looks good can be easier to understand - just so long as you put the aesthetics so far above the meaning that the meaning is lost.
    • A simple thing here is try to position elements so that their layout makes sense (e.g. by layers or tier) - and so you have fewer connectors crossing over... when lots of connectors cross-over looks messy and people will often translate messy = complex.
    1. Don't be afraid to use a little colour if it helps bring clarity.

    For More Details [1]: https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling [2]: https://cloud.google.com/apis/design/resources