1. System design
System design is a process of defining system architecture, functional modules, services, interfaces, and data storage to meet specific requirements.
Different from object-oriented design, object-oriented design is usually the design of a specific functional module, and usually requires the design of class diagram relationships, interface relationships, implementation relationships, etc. that involve specific code levels, such as: elevator design, game design.
System design is a higher-level design based on object-oriented design, focusing on the architecture of the entire system, the collaboration and communication between components, and the realization of meeting system requirements. The key points are: meet actual needs, have scalability, stability, etc., such as Twitter and online car-hailing system design.
2. The way of design: 4S analysis method
The commonly used method and design idea of system design is 4S analysis method: Scenes, Service, Storage, Scale
- Scenes: demand scene. What are the current problems that need to be solved, what functions are needed, the current volume and the volume of future predictability
- DAU, average QPS, peak QPS and other demand indicators
- Service: system service. In order to solve these demand scenarios, what key services and key interfaces need to be provided
- HTTP service, RPC service, specific interface and core interaction between services
- Storage: system storage. Define how data of system services is stored and accessed
- Schema, NoSQL, relational storage, transaction, consistency, storage volume and other considerations
- Scale: System expansion. Solve problems that may arise with current and future systems
- Scalability, stability, degradation, circuit breaking, monitoring, etc.
System design is not always the optimal solution in one step, but the most suitable solution in the current scenario. Try to choose the simplest architecture design and storage design in the scenario that meets the current needs, and make certain expansion designs for foreseeable growth. The system design itself is weighing various technologies to solve the core demands.
3. Practical examples
Design an MVP version of the Twitter system.
3.1.Scenes
The Twitter system contains many requirements. First, define the requirements and clarify what to do:
- User registration and login
- View and modify account information
- View, search and upload tweets
- Newest/hottest/followed tweets feed display
- Tweet Like, Subscribe
- Follow, unfollow, etc.
Analyze the core requirements and priorities most needed by the current MVP version:
- P0 user registration and login
- P0 tweet view, search, upload
- P0 latest/hottest/followed tweets feed display
- View and modify P1 account information
- P1 Tweet Like, Subscribe
- P2 user follow, unfollow, etc.
Estimation of basic data indicators:
Assuming that the current MVP version DAU (daily activity) is 100,000, each user triggers the back-end API interface 100 times a day on average
- System average QPS: DAU * 100 / (24 * 60 * 60) = 115 QPS
- System peak QPS: Assuming it is 3 times the average value, then Max QPS = 3 * QPS = 345 QPS
- If each user reads an average of 50 tweets per day, the average QPS of the tweet reading interface is: DAU * 50 / (24 * 60 * 60) = 57 QPS, peak value 171 QPS
- If each user sends an average of 3 tweets, the average QPS of the tweet sending interface is: DAU * 3 / (24 * 60 * 60) = 3.5 QPS, with a peak value of 10.5 QPS
- In the same way, indicators such as daily average stored data volume, monthly average and annual average stored data volume can be analyzed
System QPS and storage level are one of the important indicators for system service selection and storage selection:
- 100QPS: An ordinary server is enough, and relational databases such as MySQL are considered for storage
- 1000QPS: Several medium servers are enough, and databases such as MySQL or Redis are considered for storage
- 100,000 QPS: Dozens of medium-sized servers form a cluster, consider Redis for caching, MongoDB or MySQL for data storage
3.2.Service
After having the core requirements, it is necessary to design the core services and interfaces to realize these requirements:
- User login and registration: UserService, interface: Login, Register, etc.
- Tweet sending and viewing: TwitterService, interface: PostTwitter, GetTwitter, FeedTwitter, etc.
- User follow/unfollow: AccountService, interface: Follow, UnFollow, FollowUsers
Core service relationship:
Service interface division and aggregation: Different interface functions should be divided, and different services should be divided to aggregate these interfaces. One service only provides corresponding interface capabilities.
3.3.Storage
With the core service and core interface, you need to consider how to store and access the corresponding data:
- UserService: store user data.
- Storage level: the current DAU is 100,000, assuming that the total number of users is DAU * 10, the total storage level is millions
- Read and write pressure: the service needs to be called internally and externally, and the read and write pressure will be greatly amplified as the business grows
- Reliability requirements: user data is the most core and critical information of the system, and no loss is allowed
- Additional considerations: index and transaction support are required, and high consistency requirements are required
- Database selection: choose a common MySQL database
- TwitterService: Store tweet data.
- Storage level: each user sends 3 tweets per day, the average annual storage capacity is DUA * 3 * 30 * 12, and the magnitude is 100 million
- Additional considerations: read QPS is much larger than write QPS, the read consistency requirements for Twitter content are not particularly high, and a certain amount of loss is allowed
- Database selection: Tweet data is usually stored in the form of documents, and tweet content can be stored in the document database MongoDB, and corresponding media information such as pictures and videos can be stored in object storage databases such as Ceph and Hdfs
After selecting the storage system, design the corresponding Scheme (storage format or constraints):
- UserService
- MySQL：User表
- TwitterService
- MongoDB: Twitters collection, each document Key is user_id, and each document stores tweets sent by users
[
{
'_id': 'xxxxxxxxx', // mongodb唯一文档id，也是推文唯一id
'title': '推文标题',
'content': '推文内容',
'create_time': 6161611717,
'modify_time': 6117171717
}
]
- Ceph/Hdfs: Media library, which stores video, pictures and other data, Key is URL, value is serialized data of corresponding media content
3.4.Scale
After designing the service, interface and corresponding storage, think about some possible problems and subsequent scalability, maintainability and stability:
- The User table uses MySQL as the database. Currently, there are millions of users, and the capacity of a single database can fully support it. If the number of subsequent users increases to tens of millions or even billions, consider migrating to sub-databases and sub-tables
- In terms of scalability: MongoDB and Hdfs/Ceph naturally support horizontal expansion without considering additional sub-databases and sub-tables
- In terms of reading and writing pressure: consider using Redis as a cache to reduce the amount of requests to MySQL
- In terms of stability: report and manage the core links, set monitoring and alarms for core storage and services, and guarantee interface SLA X 9
- Downgrade flow limiting measures: consider introducing message queues, circuit breakers, etc. to achieve smooth traffic, downgrade non-critical interfaces, etc., to ensure that core services are not hung up