6周刷了200道LeetCode，面试时大脑空白8秒。拒信48小时后送达，比我任何一次AC（Accepted，通过）都值钱。
第一题：百万并发的匹配系统
面试官开口就是：「设计一个支持100万并发用户的打车匹配系统。」
我准备了6周的分布式事务、一致性哈希、CAP定理（Consistency一致性、Availability可用性、Partition tolerance分区容错性）。全是错的。
真正考察的不是知识点背诵，而是你在压力下的决策链条。100万并发不是数字，是场景——早高峰暴雨天，司机和乘客的时空坐标每秒都在变，匹配算法要在300毫秒内算出最优解，还要考虑取消率、司机偏好、动态定价。
我当时的思路：先分片，再缓存，最后消息队列削峰。听起来对，但漏了最核心的问题——匹配的本质是双边市场的实时博弈，不是简单的键值查询。
面试官追问：「如果司机同时收到两个订单，怎么防冲突？」我答了分布式锁。他又问：「锁的粒度？」我卡住了。粒度太粗，吞吐量崩；粒度太细，复杂度爆炸。这题没有标准答案，看的是你权衡的维度。
第二题：故障时的用户体验
第二题更刁钻：「匹配服务挂了，用户端该怎么表现？」
我下意识说降级到人工调度。面试官摇头：「Uber没有人工调度员。」
正确思路是熔断后的优雅降级——保留核心功能（展示附近车辆、预估价格），关闭非核心（实时路径规划、动态定价），同时用本地缓存的最后一帧数据撑住界面，不让用户看到白屏。
我漏了关键一环：故障时的用户预期管理。直接说「系统繁忙」和说「附近车辆较少，预计等待5分钟」，留存率差出一个数量级。产品经理的直觉在这里比架构图重要。
第三题：数据一致性的陷阱
最后一题关于账单对账：「乘客扣款成功，司机没到账，怎么查？」
我讲了最终一致性、对账任务、补偿机制。面试官打断我：「如果这笔订单涉及优惠券、平台抽成、司机奖励，三个系统数据对不上，你先信谁？」
这是我在6周准备里完全没碰过的领域——业务语义优先于技术正确。财务系统的设计原则不是追求绝对一致，而是可追溯、可审计、可人工介入。我背了一肚子分布式理论，没想过钱的事。
复盘：我练错了什么
拒信里有一句话：「候选人对技术细节掌握扎实，但缺乏对业务场景的抽象能力。」
翻译成人话：我把系统设计当成了填空题，而Uber要的是应用题。
LeetCode的6周训练让我对时间复杂度脱口而出，但面试问的是——这个复杂度在真实业务里值不值得。100万并发的匹配系统，用Redis（Remote Dictionary Server，远程字典服务）集群扛读，用Kafka（一种分布式流处理平台）缓冲写，用Geohash（地理哈希）做空间索引，这些技术选型不是难点。难点是你怎么向面试官证明，你理解「匹配延迟」和「司机空驶率」之间的 trade-off（权衡）。
我后来翻遍了Uber的工程博客，发现一个细节：他们的匹配引擎每2秒重算一次全局最优，而不是实时响应每次位置更新。这是业务决策，不是技术限制。省电、省流量、省算力，牺牲的是理论上的「最优」，换来的是可落地的「足够好」。这种取舍，刷题刷不出来。
另一个盲区：我没准备「反向设计」——如果让你改造现有的Uber系统，你会动哪？面试官暗示我，他们最近在做多模态匹配（拼车+专车+外卖骑手资源共享），这需要重构调度层的抽象。我当时的回答停留在「加缓存、扩集群」的层面，没触及架构演进的核心矛盾。
给后来者的清单
如果你也在准备大厂系统设计，这几件事比刷题重要：
第一，用真实产品的数据量级做假设。Uber日均3000万单，峰值每秒10万次匹配，这些数字不是背景知识，是你算QPS（Queries Per Second，每秒查询率）、分片策略、缓存命中率的起点。脱离业务谈技术，面试官一眼识破。
第二，准备三个「如果」：如果主库挂了、如果流量涨10倍、如果业务要扩展新场景。不是背答案，是练决策速度。我面试时8秒的空白，就是平时没练过压力下的快速取舍。
第三，找到你目标公司的工程博客，读最近两年的架构演进。Uber的Ringpop（分布式节点发现）、Schemaless（无模式数据库）、以及他们怎么从单体迁移到微服务，这些不是八卦，是面试官的隐性题库。我后来才发现，第三题的对账问题，直接对应他们2018年的一篇博文。
48小时的拒信周期，比我想象中快。据说Uber今年收紧了系统设计的通过标准，同一批面试者里，有5年经验的老兵也挂在这一轮。
我的200道LeetCode没白费，但它们只是入场券。真正决定能不能拿到offer的，是你能不能在8秒内，把「技术正确」翻译成「业务价值」。我僵住的那8秒，不是知识盲区，是思维习惯的盲区——刷题让我学会了怎么答对，但没教会我怎么想对。
你现在准备系统设计，花多少时间在业务场景上？
热门跟贴