高流量应用 你没定义好需求根本无法讨论怎么设计
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 就能搞这个