SDE 系统设计面试攻略

为什么很多系统设计回答听起来很散

很多 SDE 候选人准备系统设计时，会先背大公司的经典题：设计 Twitter、设计 YouTube、设计 Uber。背这些题没有错，但如果你只记住 Kafka、Redis、CDN、sharding、microservices，面试时很容易变成术语堆叠。面试官听到很多组件，却听不到你的判断。

系统设计面试真正考察的是你能不能把一个模糊需求拆清楚，然后根据约束做合理选择。一个强答案通常从范围开始，而不是从架构开始。你先确认谁在用，核心动作是什么，哪些需求必须实时，哪些可以异步，数据是否敏感，规模假设是多少。然后你的 API、数据模型、缓存、队列和存储选择才有依据。

对早期 SDE 来说，目标不是听起来像 Principal Engineer。目标是证明你有清楚的工程推理：能从小系统开始，知道什么时候增加复杂度，知道哪里会失败，也能把 tradeoff 讲成人能听懂的话。

RoleProof 系统设计面试评分表

用这张 100 分表判断你的系统设计回答是否接近面试可用。

一个好用的开场

我会先确认范围和核心动作，然后定义 API 和数据模型，再画第一版架构。最后我会讨论瓶颈、失败场景和如果规模变大要怎么演进。

第一个检查清单

• 谁是主要用户？
• 系统最重要的 1-2 个动作是什么？
• 哪些动作必须同步完成？
• 哪些任务可以异步？
• 需要保存哪些核心数据？
• 第一版故意不做什么？
• 哪里最可能失败？

1. 先定义问题，不要先画图

很多候选人一拿到题就开始画 client、service、database。图画得快，但问题还没有定义清楚。强答案会先把范围固定下来：用户是谁，系统最重要的动作是什么，哪些需求必须支持，哪些暂时不做。

比如设计文件分享系统，可以先确认第一版只支持登录用户上传文件、生成私密分享链接、撤销分享和下载文件；暂时不做多人协作编辑、公开搜索和多区域灾备。这样 API、存储和权限判断才不会飘。

再补非功能要求：文件大小上限、下载链接有效期、是否需要病毒扫描、撤销权限多久生效、下载延迟目标、审计日志是否必须保留。这些问题会直接改变架构，而不是面试寒暄。

2. API 是你的思维骨架

系统设计里，API 能快速暴露你是否理解用户流程。不要只说“前端调用后端”。说出 endpoint、request body、response、权限、错误和幂等。

文件分享可以从 POST /upload-sessions、PUT /files/:id/complete、POST /files/:id/shares、DELETE /shares/:id、GET /files/:id/download-url 开始。解释每个接口检查 userId、文件所有者、share scope、URL 过期时间和重复请求。

通知系统则可以用 POST /notification-events、GET /notification-preferences、PATCH /notification-preferences。如果发送请求可能重试，必须讲 dedupe key 或 idempotency key。

3. 数据模型让答案变具体

没有数据模型的系统设计很容易漂。你不需要写完整 migration，但应该说出核心实体、关系、索引和状态变化。

文件分享可以有 FileObject、FileVersion、UploadSession、ShareGrant、AccessAudit。数据库保存 metadata、所有者、状态和权限；真正的文件 bytes 放 object storage。这样你能解释为什么 DB 不存大文件。

通知系统可以有 NotificationEvent、NotificationPreference、DeliveryAttempt、ProviderMessage。一条事件可能产生多次投递尝试，失败重试和 provider 返回都应该可追踪。

4. 架构从第一版开始

第一版通常可以很简单：client、API service、database、object storage 或外部 provider、background worker。只有当需求需要时，再引入 queue、cache、search index、read replica 或 sharding。

文件分享的第一版可以是 API service 负责 metadata 和权限，对象存储负责文件，worker 负责扫描和缩略图，CDN 或 signed URL 负责下载。通知系统的第一版可以是 API service 写事件，queue 承接异步投递，worker 调 provider，数据库记录 attempt。

面试官喜欢听到演进顺序。你可以说第一版如何满足需求，什么指标会让你加入缓存，什么失败会让你引入 queue，什么读取压力会让你考虑 read replica。

5. Scale 不是表演

Scale 讨论应该改变你的设计，而不是成为固定段落。你可以用 daily active users、每用户读写次数、峰值倍数和记录大小做粗估算。

例如 100 万用户里每天 10% 上传，每人 3 个文件，平均 10MB，就是每天约 30 万次上传和 3TB 新文件数据。这会把文件 bytes 推向 object storage 和 CDN，而不是让数据库承受大对象写入。

如果读取热，讨论 pagination、index、cache、CDN 或 read replica。写入热，讨论 queue、batch、幂等和事务边界。强一致需求出现时，说明哪个状态必须 transaction，哪个状态可以最终一致。

6. 失败场景让答案可信

每个系统都会坏。你应该主动讨论 provider 失败、重复请求、数据库慢查询、队列积压、权限错误、无效输入和部分成功。

文件分享最值得讲的失败包括：上传一半中断、complete 回调重复、分享撤销后旧下载链接还没过期、扫描队列积压、对象存储超时。对应的修复是 upload state、idempotency key、短期 signed URL、pending_scan 状态、重试和死信队列。

通知系统最值得讲的是重复发送、provider 失败、用户修改偏好后旧任务还在队列里、队列延迟过长。你可以用 delivery attempt 表、dedupe key、偏好二次读取、backoff 重试和 queue age alert 来回答。

7. 练习方式

每次练习都按同一顺序：范围、API、数据、架构、主流程、scale、失败、总结。录音 20 分钟，然后用评分表给自己打分。

练习时不要只画静态图。每次都走一遍 write path 和 read path：用户请求进入哪里，哪个服务验证权限，写哪张表，是否进入队列，失败后用户看到什么状态。

不要只练大厂经典题。短链接、通知偏好、文件分享、求职 tracker、评论系统、feature flag，都能训练真正的工程判断。

可以直接练的具体例子

把这一段当成练习，不要照抄。对于准备 SDE 系统设计面试，真正有价值的不是更漂亮的措辞，而是这些细节里的证明：需求、API、存储、队列、规模估算、失败场景。如果面试官连续追问两次，同一组事实仍然应该能支撑你的回答。

例子 1：文件分享系统和通知投递系统

弱回答只会说自己做过这个事情，然后停在那里。它没有说明对象是什么、约束是什么、你做了什么判断，也没有说明为什么这段经历值得招聘者相信。

更强的版本会先交代场景，再写清你负责的对象，说明你做出的选择，最后用需求、API、存储、队列、规模估算、失败场景支撑结果。重点不是把经历吹大，而是让经历变得可检查。

例子 2：把混乱经历整理成 proof

先收集原始事实：谁需要这件事，哪里不清楚或出了问题，你手上有什么数据或材料，你亲自改变了什么，之后发生了什么。然后删掉所有你在面试里解释不了的句子。

面试可用的 proof 通常很具体：它有用户或 stakeholder，有工作对象，有判断过程，有结果信号，也有仍然存在的限制。这个组合比一句漂亮但空泛的说法更难伪造，也更可信。

7 天升级计划

1. 第 1 天：收集和文件分享系统和通知投递系统相关的原始事实、截图、记录、指标、例子或证据材料。
2. 第 2 天：用一句话写清问题，并定义谁会在意这个结果。
3. 第 3 天：列出具体对象：文件、表、dashboard、工单、客户、患者、campaign、账户或流程。
4. 第 4 天：写出判断路径，包括你考虑过什么、放弃了什么、为什么这样选。
5. 第 5 天：补上证据：需求、API、存储、队列、规模估算、失败场景。如果没有数字，就用复盘记录、前后状态、演示路径或复盘记录。
6. 第 6 天：准备 3 个面试官可能追问的问题，并在不新增虚假说法的情况下回答。
7. 第 7 天：重写简历 bullet、作品集段落或面试故事，让它更短、更清楚、更容易验证。

低于招聘标准的常见错误

• 所有岗位都套同一个框架，却没有说清真实工作对象。
• 先加高级词，再找证据，导致内容听起来空。
• 写了无法解释、无法测量、无法被证据材料支撑的结果。
• 跳过取舍，让经历听起来像没有难度。
• 没有下一步：如果再给一周，你会改进、监控、测试或澄清什么。

系统设计诊断：文件分享系统和通知投递系统

系统设计面试真正考的不是图画得多复杂，而是你能不能把用户动作、数据归属、可靠性和成本放在同一个判断里。对于准备 SDE 系统设计面试，可以把文件分享系统和通知投递系统当成准备锚点，并反复回到需求、API、存储、队列、规模估算、失败场景。你的目标是留下清楚的准备线索：该收集什么工作对象、要解释什么判断、哪些证据需要经得住追问。

在润色之前，先准备需求笔记、接口草图、数据模型、流程图和失败场景清单。如果其中一块缺失，先不要急着把句子写漂亮；更好的做法是补事实，或者把说法缩小到真实可解释的范围。

定稿前先做四件事

• 写清这段系统设计回答要回答的问题。
• 说出具体对象：表、流程、账户、患者场景、功能、模型、campaign、工单或项目页面。
• 把你个人做的动作，和团队、课程、公司共同完成的结果分开。
• 补一个结果信号：指标变化、复盘记录、交付痕迹、质量改善、客户反馈或学习结论。

弱稿到强稿：改写示范

下面的写法只提供结构，最终要换成你的真实事实。强稿不是更夸张，而是更窄、更清楚、更能解释。

弱稿：“我设计了文件分享系统和通知投递系统，并考虑了扩展性。”

强稿：“我先从文件分享系统和通知投递系统里的用户动作开始，定义需求，再画出 API，最后说明哪个失败场景会改变这个设计。”

强稿更可信，是因为它给面试官留下了可以检查的材料：需求、API、存储、队列、规模估算、失败场景。同时它没有把结果说满，保留了限制，反而更像真实工作。

这个岗位专用的评分视角

系统设计完整演练：文件分享

用一个具体题练习：设计文件分享。登录用户可以上传文件、创建私密分享链接、撤销访问权限，并通过短期下载链接获取文件。第一版范围要收窄：不做多人协作编辑，不做公开搜索，也不默认做多区域 active-active，除非面试官明确加这个约束。

第二个演练：通知投递

通知系统要把“事件创建”和“消息投递”分开。强回答会定义 NotificationEvent、NotificationPreference、DeliveryAttempt 和 ProviderMessage。API service 记录事件后快速返回；worker 从队列取任务，检查用户偏好，调用 email、push 或 SMS provider，并记录每次尝试、provider 响应、重试次数和最终状态。

这里的取舍是一致性和可靠性。用户可以接受通知晚几秒，但不能接受账单提醒重复发或静默失败。回答里要说清哪里需要幂等，哪里可以接受最终一致，以及你会监控哪些指标：队列等待时间、provider 错误率、重复发送率和 p95 投递延迟。

只针对这篇攻略的练习题

1. 不用夸张词，在 45 秒内讲清文件分享系统和通知投递系统。
2. 定义最重要的证据：需求、API、存储。
3. 说明面试官或招聘者可以在哪里检查这段经历。
4. 写出一个限制，让说法保持真实。
5. 围绕需求重写一条简历 bullet、作品集说明或面试回答。
6. 回答最难追问：“你怎么知道这个解释是对的？”
7. 如果这是真实工作，下周你会先做什么。
8. 删掉一句听起来厉害但解释不了的话。