面试官问我"设计一个秒杀系统"，我聊了40分钟

上周去面试一家中厂的后端岗，前两轮技术面都顺利通过了。算法题不难，一道中等难度一道简单，十分钟搞定。项目面也聊得挺好，面试官还夸我"工程经验扎实"。

第三轮是系统设计，面试官是个40岁左右的技术总监，头发花白但眼神很锐利。他看了眼我的简历，开口就问： "设计一个短链接系统，比如bit.ly，支持每天10万次写入、100万次读取，P99延迟要小于50毫秒。你来设计一下。" 我心想这题我刷过啊，LeetCode上有类似的，刚准备画架构图——从ID生成到存储到缓存到HTTP重定向，一套标准答案。

"等等，"他打断我，"你先别画图。你告诉我，如果让你选存储方案，你会选什么？为什么选它而不选别的？" 我愣了一秒。这和题库里不一样。题库里的系统设计题，给你一个场景，你按套路画架构图就行。但这位面试官不让你背答案——他让你做选择，然后解释为什么。

我开始分析：Redis缓存热点数据，MySQL存完整信息，用Snowflake做ID生成。我选了Redis+MySQL的组合方案，理由是读多写少，缓存命中率可以做到95%以上。

他的眼神亮了亮，追问： "缓存穿透怎么办？短链接场景下，大量请求打到不存在的key上，你的MySQL扛得住吗？" 我想了想，说用布隆过滤器先拦截一层。不存在于布隆过滤器的key直接返回404，不进MySQL。他又追问： "布隆过滤器的误判率你怎么控制？数据更新后布隆过滤器怎么同步？如果短链接被删除了但布隆过滤器里还有，怎么办？"

这个问题我确实没想过。布隆过滤器不支持删除操作，这是它的基本特性。我老实说"需要重建或者用Counting Bloom Filter"。他点点头，没追问。

然后他又问了一个更开放的问题： "如果热点数据集中在某几个链接上——比如某个短链接被大V转发了，瞬间涌入100万请求——你怎么处理？" 这一轮聊了40分钟，没有一道题有标准答案。他不是在考我知道多少，是在考我怎么权衡。每一个方案他都会追问代价——性能代价、成本代价、运维复杂度代价。 （顺手推几个技术大厂的机会，前、后端or测试，感兴趣就试试 ）

后来他告诉我，2026年的面试趋势变了。不再是"你会不会"，而是"你怎么想"。 他说他面试了三十多个候选人，能完整说出CAP定理的占一半，但能解释清楚"为什么Redis不适合做持久化"的不到三成。大部分人都停留在"知道结论"的层面，追问两层就露馅。

他们现在最看重三点： 第一，工程判断力。知道什么时候该用Redis，什么时候该上MySQL，而不是把所有东西都塞进缓存。缓存不是万能药，它有自己的代价。 第二，权衡意识。10万写入和100万读取的压力完全不一样，怎么在延迟、可用性、一致性之间做取舍，比写出某个算法的代码更重要。真实系统没有完美方案，只有最合适的妥协。 第三，开放性思维。他最怕听到"这个场景我没遇到过"就卡住了，反而更欣赏"我没遇到过这个场景，但可以从这几个方向来分析"。思路比答案重要。

回来后我复盘这次面试，发现自己最大的进步不是答对了多少题，而是学会了"先思考再动手"。以前面试遇到系统设计题，上来就画图、写代码、背套路。现在会先花30秒想清楚：这个系统的核心矛盾是什么？面试官想考我什么？ 技术面试正在从"你会做题吗"变成"你会设计系统吗"。

这个变化，你准备好了吗？