# 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)&#x20;
* 快速增长的产品  Fast Growing 预测
  * MAX peak users in 3 months = Peak users **\* 2**
* 读频率 Read QPS (Queries Per Second)
  * 300k
* 写频率 Write QPS&#x20;
  * 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&#x20;
* 一台 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&#x20;
* 效率高，内存级访问速度

#### 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