系统设计题，不是拼组件，是拼定义问题的能力

你是不是也遇到过这种系统设计题：“设计一个支持百万用户的评论系统。”

你脑子里迅速浮现 Redis、Kafka、CDN、分布式缓存、长连接……

手起笔落，画了一整张架构图，自信讲完。

结果对面淡淡说了句：“Thanks, that’s all the questions I have.”

你心里咯噔一下。

我们以为是图不够大、组件不够全。

但很多时候，真正的问题是：我们一开始就没搞清楚，这个题到底要我们解决什么问题。

系统设计从来不是拼组件，而是一次结构化地澄清问题的现场考试。

很多候选人习惯性从技术出发，一上来就堆技术方案。但系统设计题的第一步，从来都不应该是“画图”，而是“问清楚”。

比如说：你设计的评论系统，是不是一定要求强实时？需不需要排序？支持编辑吗？评论是不是要审核？是面向 C 端还是内部系统？数据保留多长时间，有无合规限制？

如果你开口就说：“我们可以用 Kafka 和 Redis 缓解突发流量”，面试官可能会在心里写下：“Too early to solution. Didn’t clarify the problem space.”

不是你说得不对，而是你跳得太快。

我自己经历过一个很典型的对比。

一个候选人上来就说：“我们用 CDN + Kafka + Redis + 多活部署”。

另一个候选人则说：“我理解这题目标是支撑高并发评论展示，但我想先确认几点：比如是否实时？是否需要审核？评论量级的读写比例？系统 SLA 要求？业务上线节奏？”

后者可能比前者晚了一分钟开始画图，但五分钟后，面试官已经决定把票投给他。

系统设计题不是用来测你背了多少术语，而是测你能不能站在需求的角度，从不确定中找到确定性。

有时候不是你技术不够，而是没有暴露你的思考结构。

我推荐一个五连问思维骨架，在面对绝大多数系统题时都适用：

• 功能型需求是什么？

• 非功能性需求是什么？我们要的是性能、稳定性，还是可用性？一般系统设计面试中，性能，可用性和可扩展性通常会比较重要。

• 用户是谁？是 C 端用户、内部平台，还是第三方开发者？

• 关键场景和负载？QPS、峰值、延迟、存储量级？

• 风险点在哪里？单点故障、数据一致性、审核延迟？

这些问题不只是为了“表现自己”，而是帮你自己搞清楚你到底在设计什么。

高分候选人，不是组件讲得多，而是判断讲得稳。

他们往往不是一上来就答，而是先说：

“我想确保我理解清楚问题，我们目标是实现稳定展示评论流，对吗？我会从数据路径出发，先看写入侧，再看读取侧，再考虑缓存和一致性问题。”

这就像是个靠谱的架构师带团队 kick off 项目，而不是学生考试答题。

其实系统设计面试真正评估的只有四个关键点：

1. 你能不能澄清需求，包括功能需求和非功能性需求？
2. 你能不能分清优先级？
3. 你能不能讲清trade-off？
4. 你能不能演进式构建方案？

很多人败在第一步，讲了十分钟，面试官都没听懂你到底在解决什么问题。

而能做到后两步的，已经具备了把系统落地的信号：你不只是拼功能，而是知道每个组件的代价。

我面过一个候选人，设计一个推送系统，他没有急着讲 Pub/Sub，而是先确认：“这个系统主要面向哪类用户？是需要 100ms 内送达，还是分钟级别足够？”

在确认“分钟级别足够”后，他才决定整体方案可以牺牲部分实时性换取更高稳定性。

这句话，对技术选型的影响，比你说五种中间件更有分量。

因为他表现出了真正的判断力。

最后想说一句：系统设计题，不是架构图展示大会，而是一个投影，投影你面对未知问题时的节奏、方法和判断方式。

它是“有没有带项目经验”的外显窗口，也是“是否可以独立推进”的 proxy。

技术人真正的进阶，不是从写代码变成画图，而是从解决问题，变成定义问题。

而这，才是系统设计题的真正价值。

最后的最后推荐两个System Design Interview必看YouTube频道：

1. Mikhail Smarshchok 的 https://www.youtube.com/@SystemDesignInterview 是我看过的最好的 System Design Interview 视频系列。一共只有六个视频，值得反复观摩。唯一的缺点是白俄罗斯口音比较重，得全程开字幕。Leetcode 上的 System Design 课程也是他录制的，但更偏基础理论，而且需要付费，所以不强推。

2. ByteByteGo https://www.youtube.com/@ByteByteGo 。Alex Lu 还有配套的两本书。这个属于知名度比较高。推荐订阅他们的newsletter，能及时更新一些自己的知识。