CodeFarmer 技術週報 #8 - 後端系統設計面試框架
系統設計的面試題目通常是籠統且廣泛，且可能需要在 45 分鐘內完成，該如何有效地讓面試官捕捉到他期待的訊號，參考經典書籍來學習並做一下筆記。
嗨嗨大家，歡迎閱讀第 8 期的 CodeFarmer 技術週報，最近購入了 ByteByteGo 出版的 System Design Interview – An Insider's Guide 的中譯本《內行人才知道的系統設計面試指南》，不確定翻譯版與原文的差距如何，想說考量到價錢與閱讀速度拿來當作入門書籍應該還不錯。接下來幾期就參考這本書來做讀書筆記吧。
本期選題
其中第一章的內容算是在做整個系統設計元件的 top-down 理解，因為內容與前面這兩篇有重疊，對相關內容有興趣可以再參考以下連結：
這篇就先從「後端系統設計面試框架的四步驟」，來做一下筆記吧！
為什麼需要框架
系統設計的面試題目通常是籠統且廣泛，像是「請你設計一個 Facebook 動態牆」、「請你設計一個聊天系統」、「請你設計一個 Figma」等，以一個常見的 1hr 技術關面試流程來說，扣掉自介、簡單交流、面試者提問等環節後，可能只剩 45~50min 不到。
而面試官在這場面試中會期待能找到關於面試者的幾個訊號：
是否對各種系統元件有足夠的了解
是否能在承受壓力狀況下與團隊進行有效溝通，有提出好問題的能力
是否能以有建設性的方式解決不同意見的能力
是否在討論設計時能理解權衡取捨的重要，避免過度設計
要能在短時間釋出這些訊號最有效的方式可以參考書中提供的四個步驟。
步驟一：釐清需求 (3~10min)
因為系統設計的問題通常很廣泛且沒有標準答案，在釐清設計方向前就開始畫圖可能會是一個缺乏有效溝通的危險信號，且可能導致花太多時間在面試官認為可以忽略的細節上。
釐清需求大致上可以分成三個面向：
確認功能型需求 (Functional Requirements)：關於該系統的各種使用者會用到的實際核心功能
確認非功能型需求 (Non-Functional Requirements)：關於該系統的高可用性、可靠性、一致性、可擴展性等面向的討論
粗略估算 (back-of-the-envelope)：也稱為封底估算，類似於拿紙巾或信封做一些基本的資料量、流量估算
以下用一個之前看到蠻經典的由 Google EM 示範的 mock interview 影片《Google system design interview: Design Spotify》，示範「設計一個 Spotify」為例：
功能性需求 (約 5min 快速確認)
面試者：會需要具備哪些重要的核心功能，就我所知列出以下幾個：
可以在上面找到音樂
可以在上面找到各種播放列表
可以看到歌手清單
可以看到 podcast 列表
在這次的設計中是否只需要專注在實現其中幾個核心功能就好？
面試官：可以假設只要可以搜尋音樂並播放就好
面試者：我想到更多實際的用例像是假如我有在 Spotify 註冊並有播過幾首歌，那下次回來時我可以看到那些歷史紀錄等等，是否會需要考慮這樣的功能？
面試官：如果有時間的話可以這樣假設
非功能性需求 (影片沒做但有些教學會提到)
因為是音樂播放平台，所以在高可用性會是尤其注重的面向，不能讓使用者有突然不能使用的 downtime
隨著使用者成長，也可能需要考慮可擴展性與性能問題
一致性可能相對不那麼重要，因為目前還不需要考慮多用戶交互的功能
可靠性的部份會期待這些被上傳到系統中的歌曲都是可以找得到的
粗略估算
面試者：想確認這樣的系統中會期待需要服務多少使用者？
面試官：可以假設大約十億個使用者
面試者：那歌曲數量大約需要容納幾首歌？
面試官：可以假設大概一億首歌
面試者：了解，那根據這樣的量級，可以算出以下數據：
假設一個 mp3 音檔大概 5MB 的容量，那歌曲所佔容量可能可以達到約 500TB，也就是 0.5PB。
那如果要避免歌曲資料損毀或頻繁讀取效能問題，可以先安排做 3 個複本，因此歌曲總共需要 1.5PB。
另外假設每個歌曲的 metadata 像是歌名、歌手等資訊，每首歌如果大約佔 100B，那總共需要 10GB，如果保留更多彈性的話使用 100GB 的容量。
如果每個用戶資料大約佔 1KB，則大概需要 1TB 的容量。
影片也提到面試者這裡沒提到每天大約有多少歌曲被播放的流量等數據 (DAU、QPS 等)
另外這部份在估算時可能會花一些額外時間，也推薦先詢問面試官是否需要做粗略估算或直接進到下一步
步驟二：提出高階設計並取得認可 (10~15min)
把面試官當成討論需求的同事，一起在電子白板上畫出粗略的系統架構圖。
以上面的 Spotify 範例來看可以看到用一些方框代表客戶端、Load balancer、多台 web server 等元件，另外資料庫的部份使用 RDBMS 來儲存歌曲與使用者的資料，用 AWS S3 等 object store 來儲存歌曲資料。
另外書上提到是否將 API interface 的資料格式在這步驟討論呢，也是蠻仰賴與面試官確認此類系統是否需要做到這麼細節，或選擇聊聊下一步驟中的深入設計 (Deep dive、Drill down)。
步驟三：深入設計 (10~25min)
這步驟會根據面試官的喜好、職缺的資深程度等有不同的展開，有時在叫資深的面試過程中，討論的可能更多是系統的效能表現，就會期待把焦點集中在效能瓶頸與資源的評估。
不同的題目也有不同的討論細節：
短網址生成器：雜湊函式的設計深入討論
聊天系統：如何減少延遲、支援離線狀態等
文件共編系統：如何實作多人協作共同編輯的演算法
以上面的範例來說最後比較多集中在討論歌曲搜尋時的效能優化上，像是增加 CDN 的使用等等。
步驟四：彙整總結 (3~5min)
最後雙方可能會討論一些系統後續可以關注的方向並做總結：
希望面試者判斷此系統的瓶頸，會有什麼 trade-off 需要考量的
討論可能伺服器故障的問題及如何避免單點故障
如何監控指標、error log、如何以滾動方式導入系統等
scale curve 的下一步如何處理，如果要再往上提升支援的使用者量級呢？
利用剩下時間，提出其他可能的改進方案
以上就是本期的 CodeFarmer 技術週報的所有內容了，若內容有什麼錯誤、問題、討論也都歡迎透過以下管道與我交流，或直接留言與回覆這封電子信我也能收到：
Email：codefarmer.tw@gmail.com
喜歡本期的內容也歡迎按讚，並分享給有興趣、正在努力學習路上的朋友一起來免費訂閱週報一同交流討論，那我們就下週三見了！