后端面试走到一定阶段，系统设计题就是那道分水岭。它不像算法题有标准答案，也不像八股文能靠背诵过关。面试官抛出“设计一个短链接系统”，其实是在观察你如何拆解模糊问题、如何权衡取舍、如何从单机推到分布式。以下盘点高频题、答题框架和常见陷阱，帮你从容应对。
高频题盘点
面试官最爱问的，往往是“看似简单、实则深不见底”的题目：设计短链接、设计秒杀系统、设计Feed流、设计聊天系统、设计分布式ID生成器、设计限流器、设计订单系统、设计附近的人。这些题覆盖了高并发、海量数据、低延迟、一致性等核心挑战。比如短链接考编码与存储，秒杀考库存与削峰，Feed流考推拉模式，聊天考长连接与消息可靠。
面试官到底在考什么
不是考你能否给出完美方案，而是考四件事：需求澄清能力——你会不会问日活多少、读写比例、一致性要求；权衡能力——选Redis还是MySQL，选推还是拉，选强一致还是最终一致；扩展能力——单机到集群怎么演进；沟通能力——能否把复杂问题讲清楚。系统设计没有唯一解，展示思考过程比给出答案更重要。
四步答题框架
第一步：澄清需求。别急着画架构图。先问：用户量多大？QPS多少？读写比例？数据量级？延迟要求？一致性要求？可用性要求？比如短链接，要问日均生成多少、跳转多少、是否要自定义短码、是否要统计点击。
第二步：容量估算。简单算一下存储和带宽。假设每天1亿次跳转，每次读1KB，QPS约1200，峰值可能5000。存储：每天生成1000万条，每条100字节，一年约365GB。估算让方案有数据支撑。
第三步：设计核心。从API、数据模型、核心流程入手。短链接的API：POST /shorten 和 GET /{code}。数据模型：短码→长链接映射，可用MySQL存，短码做唯一索引。生成短码可用发号器+Base62，或哈希+冲突处理。跳转时查缓存，缓存未命中查DB，再回填。
第四步：扩展优化。单机MySQL扛不住，就分库分表，按短码哈希。缓存用Redis，热点key加本地缓存。读多写少，可加CDN？跳转302还是301？302便于统计，301减轻服务器压力。还要考虑防刷、限流、过期清理、数据一致性。
一个例子：设计短链接系统
面试官说“设计短链接”，你可以这样展开：需求是长链接转短链接，跳转时重定向。容量按日均1亿跳转估算。API两个接口。短码生成用Snowflake发号，再Base62编码，保证唯一且短。存储用MySQL分库分表，短码做分片键。缓存用Redis，热点短码永不过期。跳转流程：先查Redis，命中则302；未命中查DB，回填Redis。扩展：发号器可集群，Redis可哨兵，DB可主从。防刷用限流，统计用异步消息。最后提一句：短码回收和过期策略根据业务定。
常见陷阱
上来就写代码，忽略需求澄清；只谈功能，不谈非功能需求；不沟通，自己闷头设计；过度设计，一上来就微服务、K8s；被质疑就慌，不能自圆其说。记住：面试官可能故意挑刺，看你如何应对。承认取舍，解释原因，比死撑更好。
准备建议
多练经典题，每个题按四步法写一遍。看《系统设计面试的底牌》《数据密集型应用系统设计》。总结自己的模板：需求、估算、API、数据、流程、扩展、容错。找朋友模拟，练习边说边画。面试时先问清楚，再动笔，保持互动。
系统设计没有标准答案，但有好思路。掌握框架，积累案例，你就能在面试中展现出后端工程师应有的全局视野和工程判断力。
