系统设计面试：一套可复用的框架

2026-07-18 · 9 分钟阅读

系统设计这一轮挂掉的人，多半不是因为不知道缓存是什么，而是因为讲散了。没有结构，四十五分钟就消失在问题的某一个角落里，面试官始终没看到广度。这篇给你一套几乎任何题面都能照跑的框架、六道反复出现的题，以及那些悄悄拖垮强候选人的错误。

为什么结构比知识更重要

资深面试官打分的不是“你的方案是不是那个正确答案”——根本没有那个答案。他在看你怎么想：动手之前会不会先澄清、会不会推理取舍、知不知道瓶颈在哪。一个从容地把一份普通方案讲清楚的人，通常分数高过一个懂得更多但跳来跳去的人。结构本身就是信号。

每次都照跑的那套框架

时间大致按这个顺序分配。比例比具体分钟数更重要。

澄清需求（约 15%）。把功能性需求（“用户可以发帖和关注”）和非功能性需求（规模、延迟、一致性、可用性）分开。要一个粗略的数字：多少用户、读写比、单条数据多大。
估算规模（约 10%）。做信封背面的算术：每秒请求数、一年的存储、带宽。它决定整份设计——100 QPS 和 100 万 QPS 是两道不同的题。
定义接口和数据模型（约 15%）。几个端点，加上核心实体。后面所有东西都锚在这里。
画出整体架构（约 25%）。客户端、负载均衡、服务、数据库、缓存、队列。先保持简单——哪里被追问，再往哪里加深度。
在关键处深入（约 25%）。挑那个有意思的瓶颈钻进去：热点读路径、写扩散、存储选型。资深信号就住在这一段里。
收在瓶颈和取舍上（约 10%）。单点故障、热点、一致性与可用性的取舍。顺便说出你会监控什么。

你会反复伸手去拿的那几根杠杆

几乎所有设计都是由同样的几块拼起来的。关键是知道每一块在什么时候才配上场：

缓存——砍掉读延迟和数据库压力；要谈失效和陈旧数据。
负载均衡——分摊流量；无状态服务的水平扩展。
副本——可用性和读扩展；代价是一致性延迟。
分片——把写入和存储扩到单机之外；小心热点分片。
消息队列——解耦生产者和消费者；削峰；把重活变成异步。
CDN——把静态和可缓存内容推到离用户近的地方。

本事不在于把这些名词列出来，而在于说清楚这道题到底需要哪几个，以及每一个各自的代价。

反复出现的六道题

如果这六道你都能从容地设计出来，大部分变体你也接得住：

设计一个短链接服务（key 生成、跳转读路径、访问统计）。
设计信息流 / Feed（写扩散还是读扩散、排序、大 V 热点）。
设计即时通讯系统（投递保证、在线状态、消息顺序）。
设计限流器（令牌桶、分布式计数）。
设计文件存储与分享（元数据与大对象分离、去重、一致性）。
设计打车或附近搜索（地理索引、匹配）。

它们反复出现，是因为每一道都逼你面对一个不同的取舍——写扩散、地理索引、投递语义。想看实时助手在这类题面上怎么把回答结构化，可以看我们的系统设计面试 AI 页面。

悄悄扣掉你分数的错误

还没澄清就开始搭。在不知道读写比之前就跳到表结构，是经验不足的信号。
哪儿都浅。十个组件各碰三十秒，等于没有深度。选一个，钻进去。
不谈数字。没有估算撑着的“这个能扛得住”，什么都没说。
没有取舍。每一个选择都有代价。“我会加缓存，但它带来陈旧数据，我用较短的 TTL 把它兜住”——这句话本身就是全部功夫所在。
沉默。面试官只能给说出口的东西打分。把你的思考讲出来。

怎么练

从上面的清单里挑一道，出声把整套框架从头跑到尾，限时四十五分钟——最好用白板或一张空文档，不看笔记。录下来，或者找个同伴。然后复盘时间到底花在了哪里：大多数人会发现自己在数据模型上耗了三十分钟，压根没走到扩展那一步。换不同类型的题做上五次，这套结构就会变成肌肉记忆——而肌肉记忆正是那天让你腾出脑子去真正思考的东西。