题目重点：Salesforce 多篇面经重复出现 Coffee Ordering/Management 设计，部分追问 SQL、扩容及顾客门店通知；本文合并同题变体，给出交易主线与故障取舍。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练范围为顾客选择门店与菜单、提交订单、门店接单/制作/出餐、顾客收到状态通知；支付接入和库存扣减仅作为需要澄清的扩展，示例按预付费模式展开。
- 示例峰值为 1 万门店、每秒 2000 次菜单读和 200 次新订单，数字用于推演分区与队列，不是 Salesforce 原题规模。订单需要按门店本地时间展示，但服务内部时间统一 UTC。
- 每个订单只由一个门店处理，顾客不得在制作后随意取消；若业务要求跨门店转单或配送，必须扩展状态机与补偿。
解题路线
- 先定义 API 和模型：stores、menu_items(version,availability)、orders(order_id,store_id,user_id,state,total,version)、order_items 和 order_events。创建订单使用客户端幂等键；服务端在同一事务中固定价格快照、创建订单、写 outbox 事件，避免菜单涨价后历史金额变化。
- 状态从 placed→accepted→preparing→ready→completed；拒单、取消和支付失败是明确的旁支。状态更新用 version 条件写和合法转移表，防止顾客取消与门店接单同时发生时双重终态。支付授权/捕获若失败，以补偿或明确 pending 状态处理，不能把两套数据库写入假装成原子事务。
- 门店工作台按 store_id 订阅/轮询新订单，订单事件经 outbox 投递到消息系统；顾客推送、短信或站内信由独立 notification worker 消费。事件以 order_id+version 去重，通知失败重试不会重新创建订单，重复送达也不能让门店制作两次。
- 读扩容：菜单/门店信息缓存与 CDN，变更时按版本失效。写扩容：按 store_id 分区让单店订单尽量在同一分区有序处理，热点门店单独扩容工作台消费者；全局订单查询用用户索引/读模型。高峰时限制下单队列长度并给可解释等待时间，而不是无限接单。
- 关键监控包括下单成功率、支付授权失败、门店接单延迟、制作超时、通知投递延迟、单店队列积压和重复状态事件。SQL 追问可以基于固定 orders 状态与支付口径回答，但不同面试帖未给统一 schema。
手动走一遍
训练例：顾客在门店 A 提交两杯咖啡，幂等键 K。订单服务固定菜单版本和价格，提交订单与 outbox 事件；门店工作台收到 placed 后接单，状态变 accepted，顾客看到通知。若消息投递重试两次，门店按 order_id+version 只处理一次。门店制作完标 ready；若顾客在 accepted 后请求取消，服务按事先约定的取消规则拒绝或走人工退款，不把状态改回 placed。
规模与取舍
按训练峰值 200 次下单/秒、平均每单 3 个 item，订单表约 17.3 百万行/日、item 行约 51.8 百万/日；这是极端持续峰值上界，真实容量应按峰值持续时间与保留期重新算。菜单读 2000 QPS 可用缓存减轻 DB；写路径的主要瓶颈是单店热点、支付延迟和通知/工作台积压，而非仅总 QPS。分区、索引和冷热归档需按门店分布与查询模式实测。
易错点与追问
容易失分的边界
- 菜单只存当前价格，历史订单回看时金额随菜单变化。
- 下单和发送消息双写且无 outbox，出现订单已创建但门店永远看不到的状态。
- 把通知成功当订单成功，或把通知失败重新触发下单，导致重复制作。
- 只讨论全局扩容，不看某家热门门店的排队、制作容量和接单延迟。
- 未定义合法状态转移与取消边界，顾客、门店和支付回调并发时产生矛盾终态。
继续深挖
- 如何用 SQL 找上月净消费最高用户和从未下单用户？先统一已支付、退款、时区与同分口径；另有独立 SQL 题解。
- 门店临时缺货时是拒单、替代品确认还是先扣库存？如何给顾客与门店双方展示一致状态？
- 如果同一门店短时间涌入大量订单，如何做可接受产能估计、限流与预计取餐时间？
- 如果支付成功但订单事务失败，如何用幂等支付键与对账流程完成退款或补建订单？
