後端工程師的面試關卡，除了基本的程式設計之外，常見的一關的就是系統設計，堪稱後端工程師的申論題，沒有絕對的標準答案，但有好答案與壞答案之分。
系統設計面試流程
在這一個關卡中，面試者通常會被要求從零開始設計 1 個系統，常見的題目如下：
- 縮網址系統 （ 如 TinyURL, Bit,ly, Picsee ）
- 網路爬蟲 （如比價系統、搜尋系統）
- 購票系統 （如 KKTIX ）
- 串流服務 （如 Netflix, Disney+ ）
- 社交網站 （如 Facebook, Twitter, Instagram ）
- 聊天服務 （如 Facebook Messanger, Telegram ）
p.s. 更多題型可以透過 Google 搜尋，關鍵字是 “system design interview” 。
有些面試官會詳細列出需求，例如系統需要承載多少使用者、多少連線數、多少筆資料，或者系統需於多少時間內完成資料處理等等，也有些面試官會相當簡略地只提到要設計什麼系統⋯⋯。
上述 2 種作法都有各自的目的考量：
- 會詳細列出需求的情況是希望面試過程能夠具有效率，雙方聚焦在題目上進行討論。
- 不會列出需求的情況則是希望了解面試者的溝通與分析能力，讓面試者能夠盡量提問釐清系統需求，以進行後續的分析與設計。
但無論如何，從收到題目到開始設計之前，我們要做的就是：
- 確認問題
- 不管有沒有詳細列出需求，此刻我們心裡一定有各式各樣的問題，畢竟 1 個系統可大可小，如果真要設計一個大型系統，那麼肯定不是面試時間內能輕鬆做好的事情，舉網路爬蟲為例，我們可能就會疑問網路爬蟲需要多即時？需不需要排程？需不需要管重複資料⋯⋯等等等的問題。先確認問題，知道問題的範疇，才能進一步釐清需求。
- 釐清需求
- 確認問題之後，就可以釐清需求，例如需要承載多少連線數、多少時間內處理多少筆資料等等，與需求相伴的還有限制條件，在此階段也可以ㄧ併釐清，例如限制只能使用某種類型的資料庫，或者限制 API 要多少時間內進行回應等等，都是很有可能的限制條件。
- 進行估算
- 釐清需求之後，就能產生估算值。舉 24 小時處理 300 萬筆資料為例，大約每秒需處理 35 筆資料( 3,000,000 / 86400 ), 也就是 RPS(requests per second) 約 35 ，如果條件限制中有提到每次處理時間約 0.5 秒，那麼粗估就需要 18 個( 35 * 0.5 )平行處理的伺服器或程式才能做到 RPS 35 ；除此之外，容量也需要進行估算，譬如快取 1 筆資料約 2kb, 那麼快取 300 萬筆資料，就約需要 5.73 GB 左右的空間，那麼在記憶體的設計上至少就要 8 GB, 當然也可以寬估一些作為備載容量。
上述這 3 個步驟都是為了能夠在進行後續系統設計時，能夠設計出題目符合要求的架構，這個階段可以想像是日常工作與 PM, 利害關係人(Stakeholder)討論溝通的過程。
設計系統架構
釐清問題、需求、限制之後，就可以開始進行答題囉，也就是系統設計！
有些公司是事先發給面試者題目，請面試者在家先寫好後以電子郵件回覆，等到面試當天再進行討論；有些則是面試當下才公開題目。
在家答題肯定身心理比較舒適，可以查詢資料、書籍等，因此面試官會對面試者的用心程度有相對高的要求，務必用心回覆，視答題時間的長短，該有的文件、資料庫設計、圖表都應盡力附上，建議可以用 Draw.io 繪製系統架構圖，該線上工具內建常見的系統元件圖，可以迅速畫出有品質的系統架構圖。
如果是 on-site 面試的狀況下，現場大概率會提供白板可以畫系統架構，所以熟悉一些圖示怎麼畫也是不錯的，因為可以改善所有面試參與人員的溝通效率，讓大家可以輕鬆進入狀況。
畫圖的次序，可以先從確定程度較高的部分開始畫起，通常應該都是 API 伺服器，接著是資料庫或快取伺服器，最後開始往接近使用者的前端開始畫起，此處可以視需求加上 reverse proxy, load balancer 或者 API gateway 等元件。
畫完圖之後，代表你對系統架構已經有粗略的想法，如果時間還夠，可以開始補上細節，例如資料表設計、儲存格式、 API 伺服器使用的協定(protocol), 前後端溝通的資料格式，甚至打算用何種程式語言等等細節都可以補上。
以下列出一些可以補充的細節。
資料庫
- 資料庫類型，如 RDBMS 或 NoSQL
- 資料庫解決方案，如 MySQL, PostgreSQL, MongoDB, Elasticsearch 等等
- Database schema, 有哪些資料表、欄位、資料型態、儲存格式、索引等等
- Primary key 的產生機制，隨機無序的 primary key 值會影響資料庫效能，詳見白話文解說 Clustered Indexes
API 伺服器
- API 伺服器所使用的協定，例如 HTTP, gRPC, WebSocket 等等
- API endpoints, 例如
/user/<userId>等等，以及它所接受的相關參數 - 伺服器如何回應錯誤
- 程式語言
快取資料庫
- 快取資料庫解決方案，例如 memcached, Redis 等等
- 快取資料的儲存格式
- 快取的 Key 值設計，例如
user::<userId>::<version>等等 - 快取的存活時間
- 快取的更新方式
前後端溝通
- 資料格式，例如 XML, JSON,
multipart/form-data等等
此階段通常受限時間限制，肯定無法盡善盡美，但系統設計天生就是 1 個迭代的過程，經常是發現問題之後再提出新的解決辦法進行改善，工作實務上也是如此，所以不用在意架構完美不完美。
建議此階段以自己熟悉的技術框架進行設計為主，貿然使用不熟悉的技術框架很容易做出錯誤的設計，而且會無法清楚說明採用該技術框架的原因，十分可能讓面試官以為你對相關技術不熟稔。
p.s. 如果在此階段面試官就開始挑剔架構不符合他心目中的完美樣貌的話，很高機率不是 1 個好信號⋯⋯
驗證你的設計
設計好之後，可以想像從前端開始發出 1 個 request ，接著順著架構圖走訪你所設計的架構，看看是否能完成題目所要求的功能，如果有發現明顯錯誤就進行修正。
說明你的設計
畫完設計圖之後，接著需要對你的設計進行說明。
因為你的設計是基於你所接收到的問題、需求、條件限制等所設計的結果，所以必須詳細說明你的設計如何符合需求、條件限制等等。
討論與修正設計
通常說明完系統設計或者說明系統設計的過程，面試官就會拋出各式各樣的問題，藉此了解我們在系統設計的程度，或者藉著問題暗示我們的設計中存在什麼樣的問題，讓我們可以做修正。
常見的問題有：
- 為什麼選擇某某技術，而非選擇某某技術？ 例如為什麼選擇 RDBMS 而不是 NoSQL? 這時需要清楚說明選擇 RDBMS 的原因，如果可以的話，還可以進一步說明 2 者之間的差異。
- 如果某元件故障會發生什麼事？ 通常都是有著 單點故障(single point of failure) 的元件會被詢問這個問題，例如只有 1 個資料庫的設計，這時除了說明會發生的事情之外，也可以進一步說明如何改善，例如讀寫分離架構、叢集架構等等。
- 設計中哪些地方可能存在效能瓶頸？ 舉個儲存短網址被存取的次數為例，如果使用 RDBMS 做為資料庫，需要使用 lock 才能更新該數值，否則容易有 race conditions 的情況產生，造成數值失準，這種需要使用 lock 的地方，就會是 1 個效能瓶頸。同樣地，此問題也可以延伸詢問面試者有沒有解決辦法。
- 某某元件有存在的必要性嗎？有沒有替代方案？ 譬如使用者只是被動接收即時訊息的話，那麼設計上不見得一定要用 WebSocket 才能，也可以用傳統的定期 pulling 或者 SSE(Server-Sent Events) ，這樣問也能夠了解面試者對於替代方案的了解程度，甚至實務上也很可能人力、資源不足，因此必須妥協轉而使用實作成本較低的解決方案。
這一關會有著大量的攻防，問題的類型五花八門，為的就是盡可能地評估面試者的程度，如果有什麼不懂的技術也不用過於在意，畢竟很少有人能夠通盤了解所有技術框架，抱持討論、交流、學習的心態即可，切記不要胡說八道，勇於承認自己有不熟悉的領域並不可恥。
結論
系統設計堪稱後端工程師的申論題，這個關卡其實很仰賴日常工作的經驗累積，如果有相關的經驗，在設計上確實會比較容易切中要點。
但如果沒有相關經驗的話，平常也可以透過閱讀矽谷各大公司的技術部落格，看看他們工程部門遇到什麼問題以及如何解決，藉此增加經驗值。
此外，也可以訂閱 ByteByteGo 的 YouTube 頻道，該頻道提供不少系統面試相關的高品質教學，影片時間都不長，但是都很有內容，值得推薦。
以上！
Enjoy!
References
Load Balancer vs Reverse Proxy vs API Gateway
