System Design: Designing a Meal Delivery Application

Question

Design a meal delivery application.

Background

Like most system design questions, this question is very open-ended and can go in many different directions. This question in particular has many different moving parts: multiple client apps (customer, restaurant, or delivery driver), complex business logic (i.e., pricing), and third-party integrations for mapping and payment processing, etc. During the interview, the interviewer may want to dive into one area, so it’s important to establish the discussion in a structured way that allows for this to happen naturally.

Solution approach

We’ll use the following framework to help structure our answer. We’ll also use this for future system design questions in this course. This may not be the best or most comprehensive framework, but it should provide a baseline to start the discussion:

• Define system requirements:

  Before we begin any design, we’ll spend a few minutes agreeing on the one to two primary use cases we’ll need to cover.

• System breakdown:

  We’ll then diagram the key individual components of the system needed to address the one to two primary use cases.

• Dataflow discussion:

  We’ll discuss the necessary data points the system will need to collect and how they flow through the system.

• Scaling the design:

  We’ll talk about design choices and trade-offs to ensure that the system scales.

• Capacity modeling:

  We’ll estimate the request volume and data volume that the system will need to handle for a given time period.

Sample answer

Requirements

For this problem, we’ll focus on the following two use cases:

• Nearby restaurants feed:

  When the user opens the app, the user is able to see a list of nearby restaurants that are available for delivery to order from.

• Food delivery ordering:

  After a user submits an order, the order is processed and delivered.

We’re not covering a lot of other potential requirements, such as the onboarding of delivery drivers and restaurants and user authentication. This is mainly to keep this exercise scoped, but it may be a good followup to think through how these requirements might be handled.

Given the complexity of each use case, we’ll do a separate system breakdown, dataflow discussion, and scaling the design section for each use case.

System breakdown: Nearby restaurants feed

This is a potential architecture for the first use case. Although, we will re-use some components for the second use case as well.