System Design Systematic Approach
Systematic Approach for System Design
Requirements and Goals of the System
You should always clarify requirements at the beginning of the interview. Be sure to ask questions to find the exact scope of the system that the interviewer has in mind.
Functional Requirements
Non-Functional Requirements
Extended Requirements
Capacity Estimation and Constraints
Traffic estimates
Bandwidth estimates
Memory estimates
High level estimates
System APIs
Once we've finalized the requirements, it's always a good idea to define the system APIs. This should explicitly state what is expected from the system.
Parameters
Returns
Database Design
Defining the DB schema in the early stages of the interview would help to understand the data flow among various components and later would guide towards the data partitioning.
Database Schema
What kind of database should we use?
Basic System Design and Algorithm
Data Partitioning and Replication
Cache
Load Balancer (LB)
Purging or DB cleanup
Telemetry
Security and Permissions
系统设计基本方法 SNAKE 原则 by Qingyuan Feng
系统设计有四大要素
第一，是要满足一个需求即Requirements；
第二，对内容进行一个定义；
第三，从不同维度去考虑宏观的架构层、组件层、模块层；
第四，也要考虑到互相间交流的接口和相关传递的数据。所以这些内容一起构成了整个系统设计。
系统设计的基本方法 — SNAKE原则（Scenario, Necessary, Application, Kilobit, Evolve）
Scenario（场景）：用例Use Case/接口Interface
Necessity（限制）：查看需求Requirement/假设Assumption
Application（应用）：服务Service/算法Algorithm
Kilobit（数据）Data
Evolution（进化）
http://blog.bittiger.io/post180/
系统设计九阴真经: 4S 分析法
Scenario 场景
需要设计哪些功能，设计得多牛（需要承受多大的访问量 DAU / MAU）
Ask / Features / QPS / DAU / Interfaces
Ask
Step 1: Enumerate 罗列功能
Step 2: Sort / Rank 选出核心功能
Analysis & Predict
并发用户 Concurrent User
日活跃 * 每个用户平均请求次数 / 一天多少秒 （e.g. 150M * 60 / 86400 ~ 100k QPS）
峰值 Peak = Average Concurrent User * 3 (normally 2~ 9 times of average) (~300k QPS)
快速增长的产品 Fast Growing 预测
MAX peak users in 3 months = Peak users * 2
读频率 Read QPS (Queries Per Second)
300k
写频率 Write QPS
5k
给人用的产品一般读多写少，给机器用的一般读少写多
R PS < DB PS < IO PS
QPS = 100
用自己的笔记本
QPS = 1k
服务器
QPS = 1M
1000台服务器集群
QPS和 Web Server (服务器) / Database (数据库) 之间的关系
一台 Web Server 约承受量是 1k 的 QPS （考虑到逻辑处理时间以及数据库查询的瓶颈）
一台 SQL Database 约承受量是 <1k 的 QPS（如果 JOIN 和 INDEX query比较多的话，这个值会更小）
一台 NoSQL Database (Cassandra) 约承受量是 10k 的 QPS
一台 NoSQL Database (Memcached) 约承受量是 1M 的 QPS
Service 服务
将大系统拆分为小服务
Split / Application / Module
步骤
Step 1: Replay
重新过一遍每个需求，为每个需求添加一个服务
Step 2: Merge
归并相同的服务
什么是 服务Service?
可以认为是逻辑处理的整合
对于同一类问题的逻辑处理归并在一个Service中
把整个System细分为若干个小的Service
Storage 存储*
数据如何存储与访问
Schema / Data /SQL / NoSQL / File System
步骤
Step 1:Select
•为每个Application / Service选择合适的存储结构
Step 2:Schema
•细化数据表结构
类型
数据库系统Database
关系型数据库SQL Database
用户信息User Table
非关系型数据库NoSQL Database
推文Tweets
社交图谱Social Graph (followers)
文件系统File System
图片、视频Media Files
缓存系统Cache
不支持数据持久化Non-persistent
效率高，内存级访问速度
Scale 升级
解决缺陷，处理可能遇到的问题
Sharding / Optimize / Special Case
Step 1: Optimize
解决涉及缺陷 Solve Problems
Pull vs Push
更多功能设计 More Features
Like， Follow& Unfollow, Ads
一些特殊情形
Step 2:Maintenance
鲁棒性Robust
如果有一台服务器/数据库挂了怎么办
扩展性Scalability
如果有流量暴增，如何扩展
什么时候用Push
资源少
少写代码
实时性要求不高
用户发帖比较少
双向好友关系，灭有明星大v问题（比如朋友圈）
什么时候用Pull
资源充足
实时性要求高
From Hired in Tech System Design Course
https://www.hiredintech.com/classrooms/system-design
Step 1: Constraints and Use Cases
Figuring out scope, use cases, gather requirements about the system.
Estimates, constraints of the system.
Step 2: Abstract Design
Outlining a high-level abstract design:
Simple diagram, main components, connections between them.
Step 3: Understanding Bottlenecks
Step 4: Scaling Your Abstract Design
Last updated