此篇為筆者閱讀本書後，吸收資訊結合本身從業經驗，並搜尋網路資源去撰寫，如有任何錯誤請告知，謝謝。
書中提到，在面試中考到如何設計系統，你拿到題目後，第一件要做的事情就是釐清問題，做最有效率的溝通，這一點我十分認同。你有在再強的技術，如何不能切合真正需求方的需求，也是枉然。
步驟一：瞭解問題，確認系統設計的範圍
與學生時代考試不同，系統設計你需要先讓大腦理解這個需求情境，提出正確的問題、正確的假設、確認設計範圍的邊界。
針對系統使用者相關詢問考官，以利瞭解使用者與系統負載量：
誰會使用這個系統？那系統會有多少使用者？離峰時候有多少使用者？尖峰時候有多少使用者？ DAU (活躍用戶)有多少？
針對功能面詢問考官，以利瞭解功能設計：
使用者使用系統會使用哪些功能？該系統哪些為必要功能？哪些為非必要功能？ 使用者如何使用它？預期的輸入？預期的輸出為何？
針對架構面設計，多詢問一些問題：
預期希望處理多大量的資料？希望此系統能 handle 多少 QPS ？
第一階段先不用去詢問到太過細節的功能，先初步瞭解這個系統要設計的功能與使用者為何、使用者有多少等，然後在腦袋瓜裡整理一下這些資訊。
步驟二：提出高階設計並取得認可
可以先詢問考官喜歡看到什麼方式去溝通系統設計面，用白板或流程圖去表現出你想設計的架構，蠻常見到 UML(統一塑模語言)，以下針對幾個表達方式簡述：
- 資料流程圖 Data flow diagram，與 3 相似，強調描述功能間的資料流走向，好文參考、好文參考2
- 類別圖 Class diagram，將系統設計功能面，拆成不同的 Class 做表達，可以幫助開發者想像系統具有的屬性、功能、Schema 、類別間的依賴關係等，好文參考請點此
- 案例圖 UseCase diagram，與 1 類似，強調使用者與系統的交互，描述系統或類別提供給外界交互作用者的功能。它以外部觀察者角度來描述觀察到的系統功能，強調系統能作什麼事，好文參考
- Schema 關聯圖，這或許不是面試常見的方式，但系統設計初期，需求較不明確時，也可以先畫出 Schema，再想想看類別圖或是案例圖，筆者蠻常使用這個方式，下圖為設計會員等級與權益的初期 Schema
筆者最常使用 3 案例圖去跟 PM 與合作 RD 溝通，看到此案例圖的人可以清楚瞭解這個系統做什麼用？有什麼功能？並簡單理解其互動行為。
在設計初期最常使用 4 Schema 關聯圖幫助我自己想像不同資料的關聯，再去進階設計功能與實作面。
初探領域驅動設計這一篇也寫得很好，讓我學到許多。
以上說這麼多，這一階段很重要，面試者提供了系統設計的架構，面試官會去瞭解你的思考邏輯與題目上是否有落差，再根據此架構討論與發問。
步驟三：深入設計
這一階段面試者須根據面試官的反饋去做進階設計。
例如：
- 面試官詢問此 API 如何確認不會被 DDOS？
- 面試官詢問如果採用 AWS Queue 你會如何實作？
- 面試官詢問此設計資料庫選型會使用哪種類型的資料庫？
- 面試官詢問面試者如何做錯誤處理(Error handling)？
- 面試官詢問是否想過系統設計的快取機制？
這些問題都屬於系統設計比較細節的問題，大方向都沒問題，但魔鬼藏在細節裡，因此還是得小心回答。
步驟四：做總結 — 評估設計、時程、優先順序
如果到達這一步，你已經取得面試官的認同，接下來會討論一些延伸議題，討論此系統設計的瓶頸與未來使用者人數增加時會遇到的困難等。
除了回答考官的問題外，如果時間允許，為自己的系統設計做總結，highlight 自己系統設計的重點，盡可能去回應面試官在意的點。
心得
書中以上四個步驟，都是相當實用的知識與建議，過去寫程式或面試都常常還沒搞清楚狀況，就埋頭苦幹，先釐清問題，再去實作，才是正道。
我過去面試有被問過的系統設計題目：
- 設計一個選課系統，包含教師與學生版
- 設計一個爬蟲系統，匯出此網頁的關鍵字排行
- 如果此活動，不用 AWS Queue 實作，該怎麼做
希望未來回答與實作任何大型系統設計，都能從容完成，共勉之！
