高流量應用 你沒定義好需求根本無法討論怎麼設計
1. 資料一致性要求? 持久性要求?
如果一定要用到交易，基本上一致性和持久性就一定要，
就直接用掉 CAP 定理的 Consistency，算是最常見的瓶頸
2. 如果是寫 log 系統，這種 QPS 要破萬比網站容易多了，也很常見
在台灣，檯面下 QPS 破萬的 log 系統應該比檯面上的"網站"多
但這種系統通常送出 request 就不理他了，
因此後端可以用 kafka 之類的大量接收 至於要怎麼寫 log 與寫到哪 (通常是 HDFS)
是另一段需求
3. 如果一致性不重要，基本上就盡量設計成可以無腦 Scale out
但如果系統有做 sharding，那 Scale out 的數量非常驚人，
因此如何撐爆單台的資源就變得重要
4. 根據情境，還需要判斷 bare metal server 的重要性。
例如你程式用到 file system cache 等
5. 事情沒這麼單純，還有 latency/SLA 要求，如 95% percentile < 100ms 等
6. 外加 request payload 大小多大
7. 其實這些系統會再劃分好幾個子團隊，例如搞 storages、搞整合(dependencies)測試
真正搞大流量設計的是核心中的核心
其中因為系統通常包含非常多 components，整合測試規模可能會很複雜
我覺得還有很多我沒列到的 畢竟大流量系統的情境多元，
即使同樣的需求，不同團隊討論出的設計也不盡相同
因此在討論"大流量"沒先說好需求，那討論基本上會過於發散
如果你是靜態網站 那就 CDN 設好就能撐 QPS 一萬惹
要進大流量系統的團隊 不一定要需要先做過
即使考系統設計 也只是想知道你對於每個 Componennt 抉擇的邏輯合理性
實務上設計因為需求會更 tricky
因此建議:
a. 基本知識弄好: OS 演算法 資料結構 multithreads 寫程式基本功
語言也要夠深，知道怎麼做 Memory/CPU profiling
如果有用到如 JVM 的技術，也要知道 GC 演算法與怎麼分析與調整參數
b. 找出大流量團隊在哪，不是你進 google 就能搞這個