系统设计面试详细流程(最近要面System Design一定要看看)

宏观的流程：
Step1: 先問所有requirement, spec 這個系統需要提供什麼功能
Step2: Constrains: 問他我們需要處理多少traffic, 多少data, latency重不重要 A和C選哪個
Step3: 計算需要多少機器 要用什麼storage
Step4: Abstract design: 先畫出大架構！ 每個會出現的component都要畫出來 再看面試官希望你深入講哪個component
Step5: Scale: 讓你的system有fault tolerance, scale成大公司的系統架構

细讲：
细讲的最好方法就是举例子 下面举一个例子来详细说一下：
比如说现在要设计一个hash

第一步和第二步：
我要首先问問requirement：
我：多少資料需要進cache? 面试官： 30TB
我：expected QPS? 面试官：10M
我：eviction strategy? 面试官：LRU
我：Access pattern? 面试官：Write back(有空的話Write through, write around, write back都要知道什麼意思 利弊)
我：Latency重要嗎? 面试官： cache的用途就是降低latency
我：C or A: A（什么是CAP？）

第三步：
需要我自己手动简单计算一些 需要多少台机器 大概需要用什么storage(并不是说多么精确 但是也不要离谱)
下面是计算流程：
假設我們現在要用72GB RAM 4 core的machine
那總共以儲存data來說 需要30TB/72GB = 420台
這樣的話每台的QPS = 10M/420 = 23000, 即使所有core都用了 每個core要處理6000QPS
代表說 1/6000 = 167us 搭配上面那個link可知道即使是ram sequentially read 1MB要250M 所以我們如果用這個size的machine 會無法負荷
改變主意 假設現在用16GB RAM 4core的machine
30TB/16GB = 1875台, QPS per CPU = 10M/1875/4 = 1400QPS = 700us per queries. 這個數字負擔小多了。
总结一下 上面的流程大概就是：
先用data constrain算出要幾台機器 -》再用traffic constrain算看看這樣的配置合不合理-》這樣做完你就知道你的system是需要猛的機器少台一點 還是差一點的機器多台一點

第四步：
画出大体架构
见Notes for Harvard CS75 Web Development Lecture 9 Scalability（解答系统设计中的scale的问题）述

第五步：
scale:
這時候小system畫完了 如果要scale的話需要什麼東西 不外乎就是load balancer啦 DB就是可能要master-slave或是multi-master 這種東西
至於怎麼fault tolerance呢 常見的處理就是replication 就是一樣的資料存很多地方 假設有P個replication
因為每次寫和讀都寫進/讀出這P個地方非常花時間 那該怎麼辦呢
假設寫的時候 只要有W個replication confirm update我就return to user
假設讀的時候 只要有R個replication給我一個一樣的value, 我就return這個value給user
depends on design的use case(這就是為什麼use case很重要) 你要看read跟write哪一個operation可以承受高一些的latency
如果要求read很快 write可以慢一點沒關係 那就可以設R = 1, W = P, 反之可以設R = P, W = 1
總之 只要R+W > N 那這database就是strong consistent! 如果真的要求高速度的話就必須犧牲consistent 那R+W就會<P(weak consistent)
這些也不是一時半刻講得完的 有需要的話我再補充 打到這邊有點累了