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

## Replication & fault tolerance
It is imperative that we identify the various points of failure in the system and try to have a **replica/backup** for each if any component dies. Each service should be horizontally scalable. Moreover, the **NoSQL** infrastructure will also have *multiple* nodes, and the search system can also have *multiple* nodes set up. Queues can have *partitions* and *replication* as well. 



Each service/component can be individually scaled if needed. Autoscaling could be enabled to handle loads on individual components, for example, spinning up more instances in the face of a high peak load. Furthermore, if any of the nodes or any partition in the queueing infrastructure goes down, another instance can take up the job. The crashed node can then do a cleanup and restart using a process called self-healing.

# Load balancing
Every service will have multiple instances running. In scenarios where the communication is over, https `POST`/`GET` etc., load balancers should be placed in front of the individual services. Load balancing helps make sure that no single instance is inundated with a deluge of requests and the response time is faster overall. Several load balancing techniques could be used like the **Least Connection Method**, **Round Robin method**, etc. 

In case the service solely subscribes to a particular channel/topic in the queue, the responsibility of load balancing is on the queue itself. For example, in **Kafka** ,consumer consumption divides partitions over consumer instances within a consumer group. Each consumer in the consumer group is an exclusive consumer of a fair share of partitions. This is how Kafka does load balancing of consumers in a consumer group.

# Caching
Based on recent orders in an area, most-ordered items, or on search items, data could be cached so that the Restaurant Search Service could look up such information from a distributed cache, instead of hitting the search infrastructure, and immediately return a few **recommendations**., Instead of hitting the object storage all the time, images of restaurants and dishes could be cached as well. The cache will hold the popular or most-ordered menu items/restaurants in a particular area and the search screen should show those options by default. The usage of cache definitely speeds up the viewing of search results.

Some of the popular cache technologies available in the market are **Redis**, **Hazelcast**, and **Memcached**. The **Least Recently Used (LRU)** or **Least Frequently Used (LFU)** algorithm, or a combination of both can be the cache eviction strategy for our use case. 

A **content delivery network (CDN)** could also be used as a cache in order to make local content available to users based on their geography. In our current application scenario, using a CDN will be an overkill.



Learn what can be done to reduce the effects of failure points, explore load balancing and the options of data that could be cached.

__default

Explore How to Handle Failure Points, Load Balancing, & Caching

Replication & fault tolerance