“This is the fifth day of my participation in the First Challenge 2022. For details: First Challenge 2022.”
This is a very good question, and one that most junior engineers are baffled by.
The problem is framed as a premise: “The needs are similar”, but the implementation process varies greatly. My answer to this question was not intended to be a case in point, but I thought it would be an opportunity to guide him in developing his own engineering philosophy, so I gave the following answer. Share with us to communicate, welcome to correct any problems, help me progress.
In engineering, there is a particularly important philosophy or principle: “Don’t over-design”, as well as other similar phrases like “don’t introduce anything you don’t have to”. It tells us never to design parts that we will never use. For example, when designing a house for a family of three, you can’t design a 10-story building with a bunch of high-rise water circuits for risk control and temperature systems.
And then the engineers wondered, how do we know that the system we’re designing is good enough? Several quantitative indicators are proposed here, under a certain QPS threshold: reliability, availability and stability.
QPS this is easier to understand, is designed system capacity is how much. This is generally a peak estimate for the next year or years in our production scenario. It is important to note that engineers must clearly know where the bottleneck of the system they design is and whether they need to design an expansion plan.
Reliability is the accuracy of service output, similar to 100 times calculation 1+1, 98 times return 2,2 times return 3, reliability is 98%.
Availability is 99 percent for 100 service calls and 1 failure, but it can also be calculated in terms of service time throughout the year.
Stability is the fluctuation rate of the production time of your service when it meets the design QPS, which we usually refer to as the quantile, which is TP999.
#_# I’m ten minutes out of time. Hurry up
It is to communicate and confirm these indicators with the demander before making the plan, and then design the system. Such as:
The demand of users is the background service scenario, so the QPS of the system will not be too high without “excessive” design.
User demand is data mining, then reliability can be appropriate not so strict, otherwise the data link protection is not heavy not leak this matter is enough for a team busy for a while.
The user needs the order service, then THE QPS may not be high, the reliability and availability requirements are very high, and the stability may be properly released to one or two seconds, after all, the service may be involved with a variety of transactions.
# I’m out of time…
Some common engineering practices, principles, advantages and disadvantages of each indicator can be studied separately by Google, and I can expand it into details when I have time.