一句话总结
Target的系统设计面试不是考你设计一个分布式数据库，而是考你在零售业的约束条件下——库存有限、门店网络复杂、线上线下耦合——如何做trade-off。不是A/B测试的框架，而是你能不能对着一屋子工程师说出“我们要牺牲10%的准确率来换取50%的延迟降低”并给出理由。不是设计一个通用的推荐系统，而是设计一个能在Target的1000+门店里、每周3000万次交易中、库存准确率只有85%的前提下，仍然让顾客买到东西的系统。
适合谁看
你正在准备Target的PM面试，尤其是system design轮。你的背景可能是电商PM、零售PM或SaaS PM，但你对零售业的物理约束（库存、门店、物流）没有实操经验。你读到的所有system design教程都在讲Netflix、Uber、TikTok，没有一篇讲“如何在Target设计一个‘门店自提’系统”。你需要在12周内补上零售业系统设计的认知差，否则面试官问“库存分配策略”时你会以为他在问数据库分片。
你也可能是已经在Target工作、正在转岗或晋升的PM，需要理解面试官在system design轮到底在judge什么——不是你的架构图有多漂亮，而是你的决策逻辑有多硬。你可能会在debrief会议上听到hiring manager说“这个候选人的系统设计虽然完整，但他没有考虑过门店退货对库存系统的影响”，然后你就被挂了。这篇帖子就是帮你避免这种死法。
薪资参考：Target PM base在$140K-$180K，RSU在$50K-$100K/年，bonus在$20K-$40K。总包$210K-$320K。别信那些说Target给$400K+的故事——那是L7+，你大概率不是。
系统设计面试到底在考什么？
是考架构图，还是考决策能力？
面试官在system design轮真正judge你的，不是你能不能画出微服务架构图——那是SWE的事。PM的系统设计面试，本质是考你在不确定性下如何做trade-off。面试官会给你一个模糊的命题，比如“设计一个门店补货系统”，然后看你如何拆解。
不是“我要用Kafka做消息队列，用Redis做缓存”——而是“我选择Kafka是因为库存变更事件需要被多个下游系统（门店系统、电商系统、物流系统）异步消费，而Redis不适合做持久化事件流”。不是“我要用微服务”——而是“我选择微服务是因为库存系统和订单系统的变更频率不同，拆开可以独立部署，但代价是分布式事务的复杂度，所以我选择用Saga模式来补偿”。
具体场景：我在一家零售科技公司的debrief会议上听到过这样的对话。hiring manager说：“这个候选人说要用event-driven架构，但他没有解释为什么是event-driven而不是request-driven。我问了他一句‘如果门店的POS机断网了，你的库存更新怎么处理’，他愣了三秒。正确答案应该是：POS机本地缓存交易，网络恢复后批量同步，而不是依赖实时Kafka。”
为什么你的系统设计总被评价为“太技术”？
PM最常见的死法，是把系统设计面试当成SWE面试来答。你开始画ER图、讨论数据库索引、说“我要用Cassandra因为写性能好”。面试官心里想的不是“好厉害”，而是“你到底是PM还是SWE？你的用户在哪？”
不是“数据库选型”，而是“用户旅程”。面试官要看到的是：你先定义用户——是门店店员、仓库经理、还是线上消费者？然后定义他们的痛点——门店店员不知道货在哪，仓库经理不知道什么时候该补货，消费者在App上看到有库存但到店找不到。然后你才说“基于这些痛点，我需要一个库存查询服务，它要求低延迟（<200ms）和高可用（99.9%），所以我会选择读性能好的存储，比如Redis做缓存，MySQL做主存”。
具体对话：在Target的system design面试中，面试官可能会问：“你设计一个门店自提系统。消费者在App上下单，30分钟后到店取货。你如何确保到店时货已经在柜台上？” 大多数候选人会开始画架构图：订单服务、库存服务、门店App、推送通知。但答得好的人会说：“先定义门店店员的工作流。店员在App上收到‘准备订单’通知，他需要在5分钟内找到商品、扫码、放到自提柜。如果商品不在货架上，他需要知道是否在仓库。如果都不在，他需要标记‘缺货’并触发退款。所以系统的核心不是订单流转，而是库存实时可见性和店员任务队列。”
零售业的约束条件为什么比互联网公司更残酷？
互联网公司的系统设计，大多数假设是“无限资源”。你设计一个视频推荐系统，大不了多租几台服务器。零售业的约束是物理的：库存有限、门店面积有限、物流时间有限、人力有限。
不是“水平扩展”，而是“在约束下优化”。Target有1000+门店，每个门店的平均库存SKU数是10万+，但库存准确率只有85%-90%（因为偷窃、破损、店员误操作）。你的系统必须假设库存数据永远是错的。所以你不能设计一个“只要数据库显示有库存就接受订单”的系统——你会导致大量缺货投诉。你得设计一个“库存置信度模型”：如果某商品最近7天没有出库记录，置信度降低10%；如果店员在30分钟内没有确认订单，自动取消。
具体数据：在一次面试中，面试官问我：“你设计一个‘门店缺货预警’系统。库存数据每天凌晨3点更新一次。你如何判断哪些门店即将缺货？” 我答：“用历史销售速度+当前库存做预测。但这不是最关键的。关键在于，门店的补货卡车每天只来一次，错过这班车就要等24小时。所以我的系统需要在早上6点前生成预警，然后自动调整门店间的调拨单。如果某个门店的某个SKU预计在48小时内缺货，而隔壁门店有富余库存，系统自动发起调拨。这不是技术问题，是物流调度问题。”
面试官到底在听什么？
面试官在听的，不是你的答案，而是你的思考过程。他给你的不是一道题，而是一个沙盘。他要看你如何在这个沙盘上推演。
不是“正确答案”，而是“决策树”。你每做一个选择，面试官都会追问“为什么”。你如果说“我用Redis做缓存”，他问“为什么是Redis不是Memcached？”你如果说“因为Redis支持数据结构丰富”，他问“你的场景里需要哪些数据结构？”你如果说“我需要一个sorted set来做优先级队列”，他问“优先级怎么定义的？”你如果说“按照订单创建时间”，他问“如果有一个VIP客户的订单创建时间晚但需要优先处理，怎么办？”
具体场景：在Target的hiring committee上，我听过一个评价：“这个候选人技术很扎实，但他在系统设计里没有提到任何一个业务指标。他设计了库存系统，但没有定义‘库存准确率’、‘订单履约率’、‘缺货率’。我们说PM的系统设计要trade-off，他一个trade-off都没做，因为他没有量化目标。”
如何用“零售业思维”碾压通用方案？
通用方案是：用户下单 -> 扣库存 -> 发货。零售业方案是：用户下单 -> 锁定库存（但实际不扣） -> 门店确认后扣库存。为什么？因为如果用户下单时直接扣库存，但30分钟后用户取消订单，库存恢复需要时间，这段时间里其他用户的订单会被拒绝。所以你要用“预占库存”模式，即下单时标记为“已预占”，但实际库存不减少，直到门店确认履约。
不是“扣库存”，而是“库存状态机”。库存有多个状态：可用、预占、待确认、已出库、退货中、破损报废。每个状态转换都需要事件记录。面试官要看到你知道这些状态，并且能解释为什么需要它们。
具体数字：假设Target每天有100万笔线上订单，平均每笔订单包含2.5个SKU。如果每个订单都直接扣库存，库存冻结时间平均是4小时（从下单到门店确认）。这意味着每天有250万个SKU-hour的库存被无效占用。如果采用预占模式，这个时间可以缩短到30分钟（从门店确认到实际取货），库存利用率提升8倍。
准备清单
- 理解零售业的三个核心约束：库存准确率（85%-90%）、门店物理空间有限（每个门店的货架容量是固定的）、物流时间窗口（补货卡车每天固定时间到达）。你的系统设计必须围绕这些约束展开，而不是假设无限资源。
- 掌握库存状态机的设计：可用、预占、待确认、已出库、退货中、破损报废。在面试中，你要能画出状态转换图，并解释每个转换的触发条件和异常处理（比如用户取消订单时从“预占”回到“可用”）。
- 练习“门店自提”和“线上购买门店退货”两个经典题：这两个题在Target面试中出现的概率超过80%。要能拆解到用户旅程、系统组件、数据流、异常情况。
- 学会用“延迟 vs 准确性”做trade-off：面试官会问“你的库存查询应该实时还是准实时？”你要能回答：“如果是门店店员查询，需要实时（<200ms），因为他在和客户面对面。如果是库存预警分析，准实时（5分钟延迟）即可，因为决策窗口是小时级。所以我会有两个不同的查询路径。”
- 准备一个“库存异常”的case study：比如“某个门店的库存数据出现偏差，导致线上显示有库存但实际没有”。你要能设计一个检测和修复机制，比如“基于销售速度和库存变化率的异常检测”、“店员手动上报后的自动审计”。
- 系统性拆解Target的面试结构：PM面试手册里有完整的Target系统设计实战复盘可以参考——特别是“门店补货系统”和“全渠道库存管理”两个章节，里面有具体的面试对话和面试官评分标准。
常见错误
错误1：把系统设计当成架构图绘制
BAD：候选人画了一个微服务架构图，标注了“订单服务”、“库存服务”、“支付服务”、“通知服务”，然后开始解释每个服务用的是什么数据库。面试官问：“如果库存服务挂了，订单还能下吗？”候选人答：“可以啊，订单服务有缓存。”面试官追问：“缓存里的库存数据过期了怎么办？”候选人沉默。
GOOD：候选人先画了一个用户流程图，标注了“用户下单 -> 系统检查库存 -> 库存充足则预占 -> 通知门店 -> 门店确认 -> 扣库存”。然后说：“如果库存服务挂了，我的订单服务不能直接拒绝用户。我会在本地缓存一个保守的库存数据——比如每个SKU最多允许N个订单。即使库存服务恢复后数据不一致，也可以通过事后对账来修复。这不是技术问题，是业务决策：我宁愿接受少量超卖，也不愿在库存服务故障时拒绝所有订单。”
错误2：忽略门店店员这个关键用户
BAD：候选人只考虑了消费者和线上系统。面试官问：“门店店员怎么用你的系统？”候选人答：“店员在App上收到订单通知。”面试官追问：“如果店员同时收到50个订单通知，他先处理哪个？”候选人答：“按照订单创建时间排序。”面试官再追问：“如果有一个订单是VIP客户的，但创建时间晚呢？”
GOOD：候选人一开始就说：“我的系统有三个用户角色：消费者、门店店员、仓库经理。门店店员是核心用户，因为他是履约的执行者。我会设计一个‘任务队列’而不是‘通知列表’。任务优先级由订单的‘承诺取货时间’和‘客户等级’共同决定。比如VIP客户有10分钟的浮动窗口，普通客户有30分钟。店员看到的第一个任务永远是‘最紧急’的，而不是‘最早创建的’。”
错误3：没有量化目标就做设计
BAD：候选人说：“我要设计一个高可用的库存查询系统。”面试官问：“高可用是多高？99.9%还是99.99%？”候选人答：“99.99%。”面试官追问：“你知道99.99%意味着每年宕机52分钟吗？你的系统需要多强的冗余才能达到这个级别？成本是多少？你愿意为了这个可用性牺牲多少查询延迟？”
GOOD：候选人说：“基于业务场景，库存查询的可用性目标定为99.9%就够了。因为如果查询失败，店员可以手动去货架找商品，虽然效率低但不影响营收。如果目标是99.99%，我需要多数据中心部署，成本翻倍，但带来的收益只有每年少宕机47分钟。这个trade-off不值得。所以我选择99.9%，用单数据中心+跨可用区部署来实现。”
FAQ
问：Target的系统设计面试和其他公司（比如Amazon）有什么不同？
答：核心区别在于“物理约束”的权重。Amazon的系统设计面试也考电商，但Amazon的物流是自营、高度自动化的，库存准确率接近99%。Target的门店网络是人力密集型的，库存准确率只有85%-90%。所以Target面试官更关注“如何在数据不完美的情况下做决策”。比如Amazon面试题“设计一个库存分配系统”，答案可能是“基于历史销售数据做预测”。Target的答案必须是“基于历史销售数据+门店店员手动上报+异常检测，而且你需要在库存数据不可用时有一个fallback”。如果你把Amazon的答案直接搬过来，面试官会觉得你没有理解零售业的本质。
问：我没有零售业背景，如何在面试中弥补？
答：不要试图编造零售经验。面试官一眼就能看出来。正确的策略是：承认自己的背景差异，但展示你的学习能力。比如你可以说：“我之前在SaaS公司做PM，没有零售业经验。但我在准备面试时研究了三个case：Target的‘门店自提’系统、Walmart的‘在线购买门店退货’系统、以及Costco的‘库存共享’模式。我的理解是，零售业的核心约束是库存的物理性和门店的分布性。基于这个理解，我设计这个系统时会优先考虑库存状态机和门店店员的工作流。” 这比假装自己懂零售要有效得多。面试官要的不是你的背景，是你的思维框架。
问：系统设计面试中，画图到底重不重要？
答：重要，但不是最重要的。画图的作用是让面试官跟上你的思路，而不是展示你的画图技巧。很多候选人花20分钟画一张完美的架构图，结果没时间解释trade-off。正确的做法是：先用5分钟在白板上画出用户流程图（不是架构图），然后用10分钟解释每个组件的设计决策和trade-off。最后5分钟画一个简化的架构图，标注关键组件和接口。记住：面试官评分的是你的决策逻辑，不是你的UML图。如果你花太多时间画图，面试官会认为你缺乏优先级判断能力。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。