考察点

1. 交流沟通和理解能力：充分交流理解所设计系统的目标，方便做设计中的tradeoff
1. 询问系统商业目的，解决什么问题，用户特点
2. 功能性需求 and 非功能性需求
3. 跟着面试官思路走就好了

2. 资源估算：达到我们所要求的QPS和latency，需要多少资源
1. 理解系统瓶颈
2. 计算流量、存储
3. 计算机器规模

3. 设计和架构能力：核心部分
1. 架构图
2. 数据结构与存储
3. 核心子服务设计，支持scale
4. 接口设计
5. 专题深挖（optional）

4. 扩展性 (Scalability)，容错性，延迟要求
1. 一般在第二轮设计才考虑，优先满足设计和架构
2. 还需要考虑日志、监控、报警、容灾

要点

• 平衡取舍 ⇒ 要有方案和组件的对比，做出合适的选择

• 预判未来 ⇒ 如果未来规模到了xxx/需要加入yyy怎么办？系统瓶颈和风险在哪？

• 抽象思维 ⇒ 宏观上，会画架构图和数据流图；微观上，做好API和数据结构的设计

• 容错能力 ⇒ xxx部分不行了怎么办

• 业界调研 ⇒ 有哪些解决方案可供参考？内部/社区有哪些基础组件？

流程框架

1. 明确需求（问清楚了再开始）
1. 功能性需求（系统具体功能？）
2. 非功能性需求
1. 高可用
2. 低延迟
3. 一致性
4. 分区
5. 流量模式、特点

2. 粗略估计
1. 系统规模
1. 用户量
2. 日活用户DAU
3. 段时间内平均QPS
2. 存储空间（数据量？文字 or 图片 or 音视频？）
3. 网络带宽

3. 设计API
1. 鉴权
2. REST

4. 数据模型
1. SQL or NoSQL？用什么库？
2. 有没有图片、视频需要用到对象存储？
3. 数据分区？（垂直、水平）
4. 索引？

5. 绘制架构
1. 负载均衡
2. 应用服务器
3. cache/filter
4. 数据库
5. 中间件（mq、分布式锁）
6. 对象存储

6. 顺着面试官的关注点，深挖两三个组件
1. 优缺点
2. 选它的原因

7. 找出瓶颈，试着解决
1. 是否存在单点故障？怎么缓解？
2. 数据副本的量够不够？挂掉几台服务器仍然可以为用户提供服务？
3. 服务之间的关联性强不强？会不会互相影响？
4. 服务的性能怎么监控？怎么报警？
5. 如果当前支持100w用户，如何扩展到以支持1000w？

常见问题

• 我们将做哪些具体的功能？它们之间的权重/优先级怎么样？

• 这个产品有多少用户？日活？

• 公司预计以多快的速度扩大规模？3个月、6个月和一年的预期规模是什么？

• 公司的技术栈是什么？

• 做移动端APP/小程序/web？

面试 Tips

1. 很可能就是让你设计一个常用的产品X，问题往往十分含糊。要知道，一个人怎么可能在一个小时内设计出一款受欢迎的产品，而这种产品需要数百甚至数千名工程师来完成？显然，没人指望你这么做。现实世界的系统设计极其复杂。

2. 系统设计面试，是为了模拟现实生活中解决问题的过程，两位同事就一个模棱两可的问题进行合作，并提出一个满足他们目标的解决方案。这个问题是无止境的，没有完美的答案。与你在设计过程中投入的工作相比，最终的设计并不重要。这可以让你展示你的设计技能，捍卫你的设计选择，并以建设性的方式回应反馈。

3. 很多工程师的一个通病，是喜欢过度设计，因为他们喜欢设计的纯粹性，而忽略了trade-off。他们往往没有意识到过度设计系统引入的成本，许多公司为此付出了高昂的代价。不要在系统设计面试中表现出这种倾向。

4. 永远不要说你的设计是完美的，没什么可以改进的了！！！总有需要改进的地方的。这是一个展示你批判性思维的好机会，也会给面试官留下好印象。

5. 不要假设，不确定就问。