题目重点：整合三篇系统设计面经的 individual/bulk merchant update：对象存储上传、异步校验、分区写入、幂等恢复与版本可见性。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版商品记录以 (merchantId,productId) 唯一定位，支持单条 upsert 和 CSV 批量导入；商品详情查询要看到一条明确版本。
- 假设单条更新每秒 200 次、每日 1,000 个 CSV 文件、每文件至多百万行；这是容量推演数字，不是题目要求。
- 批量允许异步分钟级完成；是否整文件原子发布、允许部分行成功或覆盖单条较新更新必须向面试官确认。
解题路线
- 单条 PUT/PATCH 先鉴权和校验 merchantId、商品 schema 与幂等键，再按当前 version 做条件写入；重复请求返回同一结果。
- 批量先签发有限期上传地址直传对象存储，创建 import job；worker 流式读取 CSV，检查字段、重复行与非法价格，把行级错误落到可下载报告。
- 按 merchantId/productId 分区投递有效行，减少同商品并发覆盖；每行携带 importId、行号、目标版本，消费者幂等写入，失败可重放。
- 发布语义可选：部分成功适合大文件和错误反馈；若业务要求整批可见，先写 staging version，全部验证后原子切换商家可见版本。
- 查询路径通过主存储/索引读取已发布版本；监控导入成功率、行级失败、积压、重复投递、单条与批量冲突和旧版本回滚。
手动走一遍
商家上传 50 万行 CSV，系统返回 importId 后异步处理。第 10 万行价格非法，若按部分成功语义，该行入错误报告，其余行按商品 key 幂等导入；若选择整批原子发布，任何校验失败都不切换可见版本。期间商家单条改了某商品，导入必须按约定的版本优先级处理，不能静默覆盖新值。
规模与取舍
F 行文件需 O(F) 解析与验证，流式 worker 内存可按批次 B 控制在 O(B)；若 1,000×100 万行/日，平均约 1.16 万行/秒，峰值、重试和每行存储写放大需另估。分区数由热点商家和目标吞吐决定。
易错点与追问
容易失分的边界
- 让应用服务器接收整个巨大 CSV 并同步处理，容易超时和耗尽内存。
- 只给 job 状态，不给行级错误与可重试进度。
- 重复消息导致库存或价格被重复覆盖。
- 单条更新与旧 CSV 导入竞争时未定义版本顺序。
- 把训练规模说成题目给的流量。
继续深挖
- 批量导入与实时单条更新冲突时，以事件时间、提交时间还是版本号为准？
- 如何支持商家撤回正在处理的文件？
- 某大商家占据多数写流量，分区和公平调度如何避免其他商家饥饿？
