① 反直觉：高级工程师 ≠ 知道更多，而是知道选择
想象一个场景：你刚升 P7，组内有人问你：
"我们 1000 万 DAU 该用什么数据库？"
初级工程师的脑回路
"哪个最快？"
→ 立刻 Google "1000 万 DAU 最佳数据库"
→ 得到答案 "Cassandra / MongoDB / CockroachDB"
→ 选一个开始 POC
高级工程师的脑回路
"我先问 5 个问题："
→ 业务读多还是写多？比例多少？
→ 事务要求？跨行强一致还是最终一致？
→ 数据结构稳定还是经常变 schema？
→ 团队熟悉什么？踩过谁的坑？
→ 预算？运维能力？合规？
看到差别了吗？初级工程师在找答案，高级工程师在找上下文。 这就是这一章要给你装的"第二个脑回路"—— 不再问 "哪个最好"，而是问 "在我这个上下文下哪个最不坏"。
💡 顺便说：那个 1000 万 DAU 的问题，答案大概率是 "PostgreSQL + Redis 就够了" —— 这个体量远没到需要 NoSQL 的程度。绝大多数 "我们 DAU 很大" 的场景都是过度设计。
② 系统设计的 5 大维度：CAP + 5
所有系统设计的选择，本质上都在这 5 根坐标轴上做妥协 —— 增加任何一个维度都要付出别的维度的代价。
| 维度 | 代表问题 | 真实数字对比 |
|---|
| 性能 | P99 多少 ms？吞吐多少 QPS？ | 主存 100ns · SSD 100μs · 同机房 0.5ms · 跨洲 150ms（差 6 个数量级） |
| 一致性 | 强一致 / 因果一致 / 最终一致？ | 银行转账 = 强一致 · 朋友圈点赞 = 最终一致（差 100ms 没人骂） |
| 可用性 | SLO 几个 9？故障恢复多久？ | 99.9% = 一年停 8.7 小时 · 99.99% = 52 分钟 · 99.999% = 5 分钟（成本指数级上升） |
| 可扩展 | 流量 10x 时方案怎么走？ | 单机 MySQL ≈ 10k QPS · 分库分表 100k · 分布式 KV 1M+（每跨一级要重构） |
| 成本 | 钱 + 人力 + 复杂度 | 单 EC2 $50/月 · 同等容量 RDS $300 · 同等容量 Spanner $3000（差 60x） |
"这 5 个我都要 5 分" —— 抱歉，物理学不答应。CAP 定理的现代延伸（PACELC 等）告诉我们： 在分布式系统里这些维度天然冲突。架构师的工作就是替业务回答"哪个能让步"。
③ 玩一玩：换个业务，雷达图完全变形
下面这个 demo 用 3 个真实业务对比 5 维度优先级。 切换场景，看雷达图的形状变化 —— 同样是高 DAU 系统，5 边形完全不同。
🎮 取舍雷达：换个业务场景，5 个维度的优先级完全不一样
场景：日订单 100 万 / 双 11 峰值 10x / 钱不能算错
洞察：一致性是底线（钱算错就上社会新闻），其他都可以让步。成本最不重要 —— 大促一秒钟少接一笔单都比对账错强。
取舍：宁可贵 3 倍，也要事务 + 异步削峰 + 对账系统三层兜底。
💡 试试把"实时聊天"和"电商订单"切换比较 —— 同样是高 DAU 系统，5 个维度的形状完全不同。 这就是为什么"哪个数据库最好"是个伪命题。
玩完这个 demo，回头看刚才那个问题"实时聊天的一致性为什么不重要" —— 因为 IM 的失败模式不是"消息发错给别人"，而是"消息发不出去"。 失败模式定义了哪个维度是命脉。
④ 5 个经典权衡：背后都有大厂踩过的坑
SQL vs NoSQL
Twitter 从 MySQL → 自研 Manhattan
Twitter 早期用 MySQL 存 tweets，关系型 + ACID 看似完美。 但用户增长到亿级后，shard 维护成本爆表（按 user_id 分库，热门用户单机被打挂；按时间分库，跨时间查询炸裂）。 2014 年 Twitter 推出自研 KV 数据库 Manhattan，放弃 ACID 换取线性扩展。取舍：放弃事务和复杂查询，换千万 QPS 的写入和线性扩展能力。
Push vs Pull
Instagram 推送大 V vs 普通用户用了两套方案
Push（写时扩散）：用户发帖 → 立刻写到所有粉丝的 timeline → 读快、写慢。 Pull（读时拉取）：用户刷 timeline → 现场查所有关注的人最近的帖 → 写快、读慢。 Instagram 普通用户用 Push（粉丝少，写一次扩散 1000 个 cache 还能扛），大 V（粉丝百万级）用 Pull（一条帖子推 1 亿粉丝直接打挂集群）。取舍：没有"对所有人都最优"的方案，按 segment 做不同设计。
强一致 vs 最终一致
购物车（最终一致） vs 银行转账（强一致）
亚马逊购物车故意选最终一致 —— 你在手机加的商品和 PC 加的可以差几秒同步，但永远不能丢。 使用 Dynamo (NoSQL，AP) + 冲突合并策略 (vector clock)。 银行转账反过来：宁可让用户等 3 秒看到余额，也不能扣了你的钱没到对方账上。取舍：问自己"用户感知不一致"和"用户感知错误"哪个更不能接受。
缓存 vs 真实
Facebook newsfeed: TAO + Memcache
Facebook 全球数十亿 DAU 看 newsfeed，每次刷新都查 DB 是不可能的。 他们建了三级缓存：浏览器 → 边缘 CDN → TAO（图数据库前置缓存）→ MySQL。 代价：缓存一致性是噩梦。 曾经因为 cache invalidation bug 让某些用户看到"自己已经删除的好友的帖子"长达 6 小时。取舍：缓存换性能，永远要为"缓存过期 bug"付出代价。
单体 vs 微服务
DocuSign 把微服务退回单体的故事
DocuSign 早期跟风拆了 30 多个微服务，结果发现： 一个业务变更要改 5-7 个服务、跨服务调用链路追踪 1 小时找不到、CI/CD 时间从 5 分钟变 45 分钟。 2018 年他们公开宣布"反向重构"：把高耦合的微服务合并回 "良好分层的单体"。 类似案例：Segment、Istio、Amazon Prime Video (2023)。取舍：微服务是组织扩展工具，不是技术先进性勋章。50 人以下团队拆出 10 个服务 = 自残。
⑤ 5 张大厂架构卡片切换
下面这个 demo 把 5 家代表性公司的真实架构做成卡片。 每张包含 5 维度雷达 + 关键决策 + 早期失败案例。 重点不是记决策，而是看不同业务的雷达形状差别有多大。
🎮 大厂架构卡片：5 家公司，5 种完全不同的取舍
🚗 Uber · 全球数千万订单 / 秒级匹配司机 / 强地理属性
关键架构决策
按地理位置分片（Geosharding）+ Schemaless（自研 MySQL on top）+ Ringpop 一致性哈希。一个城市的数据物理隔离在一组机器。
核心洞察
"全球业务 ≠ 一个全球 DB"。Uber 早期试过单库扛全球，挂得很难看。地理分片让"上海的订单"永远不会跑去查美西的机器。
早期失败案例
2014 年前 Uber 用 PostgreSQL 单库，每次跨城市查询要全表扫描；停服扩容曾导致整个 SF 区域 3 小时不能叫车。
💡 注意 5 张雷达图的形状 —— Uber 和抖音都是"性能/可扩展"顶满，但 Uber 的"一致性"是 4（订单不能错），抖音是 2（推荐错一条没事）。"高 DAU" 不是架构决策的根因，"业务取舍" 才是。
看完这 5 张卡，你应该有个感觉："大厂架构"不是一种统一的东西。 Uber 和抖音都是性能/扩展性顶满，但 Uber 的一致性是 4（订单），抖音是 2（推荐）。 微信支付的成本是 2（金融场景花钱无上限），WhatsApp 是 5（50 人团队预算紧）。 这就是为什么"抄架构"行不通—— 你得抄取舍逻辑，不是抄方案。
⑥ 系统设计 3 步思考框架：需求 → 约束 → 方案
见过太多工程师拿到题目直接画架构图 —— 这是头痛医头的反模式。 架构师的思考要走完三步：
第 1 步 · 需求
真问题是什么？
功能需求 + 非功能需求（QPS / 延迟 / 数据量 / 一致性 / 失败模式）。 没问清楚就动手 = 必返工。
第 2 步 · 约束
我有什么？不能有什么？
团队人数 / 时间 / 预算 / 现有技术栈 / 合规要求 / 不能动的依赖。 约束决定了方案空间。
第 3 步 · 方案
3-5 个备选 + 取舍论证
从约束空间里挑出 3-5 个能跑的方案，用 5 维度评分。 最后选一个 + 写清楚为什么不选另外几个。
🎯 真实例子：设计公司内部 IM 系统
需求：支持 1 对 1、群聊（≤500 人）、消息历史搜索、文件传输。问到这里要追问：跨地域吗？要不要离线消息？消息加密？需要 "已读回执"？ 最高在线人数？峰值消息率？
约束：公司 2000 人 / 5 个工程师 / 3 个月 / 必须部署在公司机房（合规）/ 不能用任何 SaaS。
方案：备选 A = 基于 Matrix 协议自建（成熟但运维重）； 备选 B = 基于 XMPP（轻但生态差）； 备选 C = WebSocket 直连 + Postgres + Redis（最简但要自己写协议）。最终选 C，理由：2000 人 + 同机房 = 性能压力极小，团队会 PG/Redis 不会 Matrix，3 个月只够做"够用"的方案。不选 A 因为运维需求超出 5 人团队能力。
留意第三步的关键："不选 A 因为..."。 架构师的方案文档要包含否决理由 —— 不然下次有人会反复问"为什么不上 Kafka"。
⑦ AI 时代的系统设计：让 ChatGPT/Claude 当对手
AI 不会替代架构师，但不用 AI 的架构师会被淘汰。关键是用对 —— 以下三个用法效果最好：
- 用 AI 当"穷举器"。画完你的方案后，问 ChatGPT："针对 [我的场景]，请列出 5 个备选架构方案，每个方案用 5 维度（性能/一致性/可用性/可扩展/成本）打分。"AI 能在 30 秒列出你没想到的 2-3 个方案 —— 不是让它替你选，是让它扩大候选集。
- 用 AI 当"对手"。把你最终方案丢给 Claude，prompt："你是一个挑剔的 Principal Engineer，请用 5 个最锋利的问题挑战我下面这个架构。"它会问出 "如果某个 region 网络分区你怎么办" 这种你可能忽略的边界 case。
- 用 AI 做容量估算。"假设 DAU 1 千万，每人每天发 50 条消息，平均消息 200B，按 3 副本存储，每月需要多少 TB？带宽峰值是多少？" —— 这种数学题让 AI 算 10 秒，你专心做判断。
⚠️ AI 在系统设计的危险用法
直接问 "我应该用什么架构" 然后照搬。AI 给的"最佳实践"是热门关键词的拼接 —— 它不知道你团队水平、不知道你预算、不知道你 6 个月后会不会被并购。取舍依赖只有你知道的上下文，AI 不可能替你做。
⑧ 检验理解：3 个真实场景题
这一章 quiz 不是选择题 —— 是场景判断题。 每题给一个真实业务上下文，问你"会优先什么 + 为什么"。 答错没关系，看解释看出"上下文驱动取舍"的思路就赚到了。
Q1.你在一家中等规模电商公司带 8 人团队，老板说「我们要做实时推荐系统，提升 GMV」。给你 3 个月。下面哪种「先做什么」最像顶级架构师？
Q2.公司要做「订阅制 SaaS 后台」，DAU 500，付费用户 50。CTO 让你设计架构。你拿出方案后他问：「为什么不上微服务？」你的最佳回答是？
Q3.你的团队要做「用户头像上传」功能。资深工程师 A 说「直接传 S3 + CloudFront」，初级工程师 B 说「我们之前用 base64 存数据库的方案不也跑得好好的吗」。下面哪个判断最准确？
这一章你应该带走的
- 系统设计的 5 维度坐标系（性能/一致性/可用性/可扩展/成本）—— 之后每章都会在这套坐标上展开
- 3 步思考框架（需求 → 约束 → 方案）—— 不要跳过前两步
- "抄取舍逻辑，不抄方案" —— 大厂架构是参考，不是答案
- AI 是穷举器和对手，不是决策者
下一章我们带着这个框架进入第一个深度专题：数据库选型 5 大维度。 SQL/NoSQL/时序/图/向量到底怎么选，每个都配真实公司选型故事。
登录后可以给这节课打分、留反馈 —— 帮我们持续改进。