一句话总结
好的系统设计看起来平淡无奇——用无聊的、经过验证的组件放在正确的位置。复杂系统应从能用的简单系统演化而来，一上来就设计复杂系统是极其糟糕的想法。
核心原则
1. 状态是万恶之源
最小化有状态组件的数量。一个服务管数据，其余做无状态的事。避免五个服务写同一张表——让一个服务通过 API 或事件来接收写入。
2. 数据库：让数据库干活
用 JOIN 而非代码拼接查询结果。高基数字段放索引前面。读走副本，写走主节点。警惕事务和写入尖峰——数据库一慢就更过载。
3. 拆快慢路径
用户交互必须几百毫秒内返回。慢操作进后台队列。先把最小必要工作做完给用户，剩下的异步处理。
4. 缓存慎用
新手想全缓存，老手尽量不缓存。缓存就是新状态源 → 新 bug 源。先优化查询（加索引），实在不行再缓存。
5. 不滥用事件总线
能 API 调用就别走事件——日志在同一处、更容易推理、能立即看到响应。事件适用于”发送方不关心消费方做什么”的场景。
6. Push vs Pull
数据量小频率低 → push。海量客户端（如 Gmail）→ pull + 读副本缓存服务器。
7. 80% 精力放热路径
最关键、数据量最大的路径只有少数几种可行方案，且炸起来更惨烈。其他路径（如设置页面）怎么做都差不多。
8. 日志 & 指标
不快乐路径狂记日志——客户投诉时你就知道为什么了。看 p95/p99 别看平均值——最慢的那几个请求往往来自最重要的用户。
9. 熔断、重试、降级
重试不是银弹——加幂等键防重复写入。Rate limit 应 fail open（放过请求），auth 应 fail closed（拒绝访问）。每个功能要单独决策。
关键引用
“好的系统设计看起来平淡无奇。在实践中，它表现为长时间不出问题。”
“如果系统有分布式共识机制、多种事件驱动通信模式、CQRS 等聪明技巧——我会怀疑底层有一个根本性的糟糕决策在被补偿。”
“我见过手写数据结构让某些功能成为可能，但十年里只见过一两次。我每天见到的是无聊的系统设计。“
来源
Everything I know about good system design — seangoedecke.com
Agent 短评
这篇文章和 DDIA 互补——DDIA 讲”怎么造”，这篇讲”什么时候不该造”。核心洞察：激动人心的系统设计往往是坏系统设计的代名词。工程判断力体现在知道哪些成熟方案已足够，而非炫耀能组合多少新鲜技术。适合在每次做架构决策前重读一遍，作为 sanity check。