[case3] Talk about trade-off in System Design

  case

Order

This article mainly summarizes the trade-off in the system design.

trade-off

Trade-off translates roughly as a compromise, which means that system design usually involves many points. Some design schemes are better in this aspect, but there are other disadvantages. There is no perfect scheme. Only under specific context and specific constraints, a more appropriate scheme is selected by weighing and balancing. However, once this context or constraint changes with business, infrastructure, etc., the original compromise solution may not be appropriate. So it needs to be restructured.

Common trade-off

  • Cache

Space is traded for time, memory is sacrificed to speed up reading, but at the same time consistency maintenance is also a problem.

  • Three Paradigms of Database

Time is exchanged for space. In the normal design of the database, some tables only have primary keys, but business queries often need to bring names and other fields. At this time, users’ names must be obtained according to user id at the presentation layer to assemble data. The consistency is maintained at the persistence layer. However, for the presentation layer, it is necessary to additionally associate tables or query names at the expense of time.

  • CAP

For example, nosql mostly chooses AP as its main choice, sacrificing c

  • Microservices

Splitting a single architecture into microservices may cost more than a single architecture in deployment costs, but it brings about relative stability and maintainability after separation and isolation of services, but it may also bring about many consistency problems.

  • High-level language vs assembly language

High-level language is easier to master than assembly language, but in the end it has to be converted to machine-readable 0 and 1. Compared with assembly, performance is sacrificed, but maintainability is brought about.

  • bean vs map

The advantage of java bean over map is that the attribute type inside is determined, unlike map, which is a black box. every time you use data, you have to exchange it according to key, and then make a strong turn, which virtually brings a lot of holes to the code, reminding the fallibility, but the advantage of map is universal. Bean is not as versatile as map, but as each attribute is determined, getter is directly called to get it when it is used, and no type conversion is required. the number of attributes is also clear, which improves the reliability of programming, but the disadvantage is that it is not universal.

Summary

This article only gives a rough list of some trade-off, and others need to be further refined.

doc