This comprehensive course prepares you for DoorDash software engineer interviews and DoorDash system design interview questions.

This course prepares you for a system design interview by using a case study of DoorDash (a prepared food delivery system) and familiarizes you with the challenges you will encounter during the interview. 

You will begin by understanding the theory behind the system design interview to give you an idea of what to expect. Next, you’ll understand how to identify a system’s requirements, handle data, and lay down the architecture of the system. Along the way, diagrams and quizzes will help you solidify your concepts.

By the end of this course, you will have a solid understanding of how to approach a system design interview, and you will have the confidence to answer a number of different scenarios, no matter the question.

System Design Interview: DoorDash

## Component design & architecture
The overall architecture could be microservices-based with heavy usage of the publisher-subscriber pattern, involving a **queuing technology** like **Kafka**, **RabbitMQ**, **ActiveMQ**, **Amazon SNS**, or **Amazon MQ**. Each microservice can talk with another using this model of publishing a message and subscribing to channels or topics. This mechanism de-couples services from each other in the best possible way. 


Consequently, microservice `A` doesn’t need to know the endpoint of microservice `B` when it publishes a message to the queue. The publisher doesn’t need to know the consumers (subscribers) of its published messages. Similarly, the subscriber doesn’t know about the source of the message, i.e., the publisher. The Pub/Sub system becomes a broker and serves as a contract between all the involved parties.

Also, it is imperative that each microservice **interacts** with its own **database** and doesn’t share with anyone else. This approach is motivated by the database-per-service paradigm. Microservice `A` doesn’t have direct access to microservice `B's` database as they are separated and individually owned.

As described earlier, the **data model** proposes the idea of just one big fat schema containing every possible table. 

Microservices architecture is opposed to this concept. **Functional partitioning** is required to grant the **ownership** of each significant table or group of tables to one microservice. That discussion is out of scope here. However, we could choose a mix of relational and non-relational databases for our data storage requirements, which is where functional partitioning becomes more pertinent. The astute reader could take up, as an exercise, the ways the given schema could be partitioned to fit into the microservices architecture.

# Various components of the system
## UI client
The application will be **accessible** via mobile, web, tablets, etc. Based on the actor, the interfaces presented will be different or a combination of many. So, individual interfaces/pages will talk to the respective service for parts of the functionality. For example, the search can be performed by the Restaurant Search Service, and orders can be handled by the Ordering Service, and so on.

Primarily, there will be **four** versions of the interface for the four actors: customer, restaurant, DoorDasher and admin.

## Search ecosystem
The most important and coveted functionality that has to be provided by the system is the capability of **searching** on menu items, cuisines, restaurants, among other things. In the food ordering journey, this functionality will be the entry point for all the customers, unless they already have a favorite restaurant in their preferences. Thus, a personalized discovery and search experience based on a customer’s past search and order history must be provided. As is apparent, this particular part of the entire system will be read-heavy.

We can think of leveraging popular off-the-shelf search offerings from the market, such as **Elasticsearch** or **Apache Solr**, for quick lookup as per user search parameters. These technologies are open-source, distributed, and based on **Apache Lucene** and have their own strengths and weaknesses.

We will need to have a queue in place to process asynchronous updates to the search cluster. When the Restaurant Profile Service (see below) creates/updates a restaurant/menu data by performing **CRUD** operations on the database, it can also post an event to the queue. This event could be any of the CRUD. We need a data indexer that listens to the queue for such events. The data indexer then picks up the event, runs a query against the database to formulate a document as per the correct format, and posts the data into the search cluster. We also need to have a Restaurant Search Service that executes queries on the search cluster based on user inputs and returns the result to be displayed on the user interface.

**Elasticsearch** has a *Geo-distance* query, which can be leveraged to return all the restaurants/menus that the user is searching for based on a defined radius from the user's location. This essentially means that users will be shown only those restaurants that are reachable from their addresses. Similarly, **Apache Solr** also has *Spatial Search*, which caters to the use case of geographic search. As such, Elasticsearch is very fast in retrieving results and can be directly queried. To further reduce latency and improve user experience, we should use a cache working alongside the Restaurant Search Service. More on caching in upcoming lessons.

The **search ecosystem** will look like the diagram below:

__default

Creating the Component Design & Architecture of the System

Component design & architecture