上周刚结束 Instacart 的 system design 轮，岗位是 senior SWE（他们内部叫 L5，不过流程里不一定都会对外说）。趁还新鲜写一下。
这一轮 60 分钟。大概 5 分钟寒暄，然后他们就直接丢题。我的题大概是：设计一个实时订单追踪系统，能支持数百万并发用户。经典题，但有 Instacart 特有的点，因为他们的订单涉及多方：shopper、customer、retailer，以及 Instacart 平台本身。他们希望你考虑这种 fan-out。
他们实际在意什么： 你怎么处理 shoppers 到 customers 的通知链路。Push vs. polling vs. WebSocket。我在 customer 端用 WebSocket，并解释了原因。 规模数字。他们会问峰值并发订单多少。我估了节假日峰值，然后他们会 probe 我的设计能不能扛住 10x。 数据库选择。他们不教条，但要你能自圆其说。我说订单交易数据用 Postgres，事件流用 Kafka，热 session/state 用 Redis。每个都被问了原因。 Tradeoffs。这点很大。他们会打断问：如果只有 6 周而不是 6 个月，你会砍掉什么。
让我意外的点： 他们比我预期更关注 shopper 侧。怎么把更新事件路由到正确的 shopper 设备上而不是广播？这直接聊了 10 分钟 pub/sub namespacing。
我通过了，进了 onsite。offer 还不确定，但这轮本身挺公平，不是挖坑。面试官是 staff eng，追问质量不错，也不会一直打断。
如果你在准备：把分布式 pub/sub 模式再过一遍，并且要想清楚外卖领域的特殊点，不要只按那种泛泛的「design Twitter（设计 Twitter）」题来背。