Hello everyone, I'm your fence teacher. In the last lesson, we mainly explained what system design is, and in this lesson, we are going to explain some common routines and some methods of system design.
Now this is an overall process of system design, which is mainly divided into these steps, so let's take it apart step by step.
First of all, the first step is called clarification. As we said in the previous lesson, clarification is a very important point in system design, so in this step we will mainly ask the interviewer some basic questions. For some topics too.
For example, Design Twitter or Design Youtube, this kind of topic is very problematic, so it is very necessary for us to narrow down the whole thing we need to design. There are a number of other common questions that we can summarize later, for example, we can ask the interviewer what exactly this project scope is, such as how much this designscope is. If it's just for us to design a very small system, such as a school project, that's a completely different approach than if we're going to design an industry-ready project.
Then we can also ask, for example, this project is mainly for a user, is it an end user, or is it for an internal team within the company, and then it does not involve UI, and then it does not involve CLI, which is the command line interface, and then it involves some other components. Questions like this are actually very useful, and we'll focus on them later, what questions we can ask at this stage of clarification, we need to emphasize that clarification, in fact, runs through every step of the way, for example, when we are doing api design.
Clarification can be done when doing database design and cost estimate. So our first step of clarification is just to give you a time to understand the system, and after clarification we should have a vague idea of what we want to design.
The next step is called requirement, which means that we go to the interviewer to find out what the specific needs are. From this stage onwards, we start to write down some real requirements on Google Doc, or else on our specific drawing software. There are two types of requirement, one is called functional requirement, and the other is called non functional requirement.
That fun functional requirement is to say that our system really provides this feature what it really provides this function, for example, a designyoutube problem, then its workflow may be divided into ordinary user upload, ordinary user ** this video. That is actually two different workflows, then this requirement is that there will be at least two different workflows, or for example, a hotel booking system, hotel booking system, this workflow may involve the function of ordinary users to book hotels, and administrator. It's this hotel manager, he may modify some hotel information, these are two different workers, we have to figure out what exactly we need to design, this is functional requirement.
Non functional requirements are the equivalent of metrics or characteristics that are hidden behind the design of the system. It is usually some characteristic characteristics to ensure that our system can function normally. Common ones are ailability, scalability, consistency, and some other metrics, such as security or some reliability, or some metrics. We'll talk about some of the differences between these metrics in the following lessons, so we won't explain them here.
After the requirement, our next step is called cost estimate. In this step, in fact, the main thing is to say that we do some calculations on some specific measurements and some data based on some information provided by some interviewers. One of the two data I use more commonly is called QPS, which is core per second, which means how many requests can come in our system in a second, and this is to measure the whole pressure of our system, to see if its pressure is high and how we scale the system in the future. And then there is another kind called storage, which is to see how much data our system stores, for example, if we make a design youtube, if our system is going to run for ten years, the number of videos stored in this youtube may be massive. If he needs to store more data, it will also affect the selection of the entire database we have later.
There is a misconception here, and many classmates will find fault with this place, and he will calculate very carefully. As an interviewer, I don't really care about the numbers, what do I care about? What I care about is a numerical level, that is, if you want to store data, you want to store a petabyte of data and a megabyte of data, and the database you choose is completely different, and the consequence is that the design of the whole system may be completely different. After a design has completed the requirement analysis and cost estimate, we should have a general understanding of the whole system, what system it wants us to design, and some requirements in all aspects of it.
Let's pause for a moment to review the first three steps in our system design process. The first step is clarification, which requires us to have an initial communication with the interviewer and then to get a rough idea of what kind of system we need to design.
The second step is requirement analysis, which requires us to further communicate with the interviewer to understand what kind of features and functions the system needs. Then the next step is cost analysis or cost estimate, which is to derive some numbers to help us understand the system.
In the next lesson, I will teach you how to draw in detail and how to do some API or database design, so stay tuned!