题目重点：题目要求汇集、保存和服务商家属性，两个上游 API 含粉丝数与成立年份；本文拆解身份匹配、时间语义、去重与服务口径。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练设计把 merchantId 作为内部主键，两个上游返回的外部 ID 经显式映射到 merchantId。粉丝数为随时间变化的指标，成立年份相对静态。
- 训练规模取 100 万商家、每商家每天更新一次，平均约 12 次更新/秒；峰值、速率限制与查询 QPS 应面试现场再定。
- 对外返回属性值、来源、observedAt 和更新状态；上游冲突以字段级优先级与最新有效采集时间判定。
解题路线
- 先问清商家身份：内部 merchantId 如何对应各上游账号，若一个商家多个账号是求和、主账号还是分开展示。错误映射会比暂时陈旧更难修复。
- 采集服务按上游独立调度，尊重限流与重试退避；原始响应落入不可变对象存储或事件日志，规范化任务将字段映射为带 source、observedAt 的标准记录。
- 每个 (merchantId, field) 经过校验、幂等键去重和冲突仲裁后写入当前快照；原始历史另存，以便上游修复和重算。
- 读 API 查询当前快照并给字段级新鲜度，热点商家加缓存；缺字段显示 unknown 与来源错误状态，不能把“未知”写成 0。
- 用采集成功率、字段缺失率、数据年龄、错误映射抽样和读请求延迟监控质量；上游不可用时服务最近可用值并标记陈旧。
手动走一遍
merchant M 在平台 A 的 followers=1200，observedAt=10:00；平台 B 返回成立年份 2018，observedAt=昨天。读 API 返回 followers=1200/source A/10:00 与 foundedYear=2018/source B/昨天。若 A 10:00 响应重试两次，幂等键只更新一次；若旧的 09:00 数据迟到，不应覆盖 10:00 快照。
规模与取舍
设 M 商家、F 字段、H 历史版本数；当前快照 O(MF) 存储，原始历史 O(H)。每个事件按 (merchantId,field) 定位为期望 O(1) KV 写入，加校验和去重；一次商家读取 O(F) 序列化。示例 100 万商家×每天一次约 11.6 次/秒只是平均值，真实设计需按峰值和上游配额估。
易错点与追问
容易失分的边界
- 把两上游同名商家直接合并而无身份映射。
- 未保留字段来源和时间，粉丝数旧值被迟到响应覆盖。
- 把缺失字段与实际 0 混为一谈。
- 上游 API 请求直接串联到每次用户查询，读延迟与可用性都受上游限制。
- 只讨论写入吞吐，忽略上游配额、变更许可和重算。
继续深挖
- 同一个商家绑定多个 social 账号时，follower 字段的口径如何定义？
- 上游返回历史修订或删除请求时，当前快照与原始历史怎样同步处理？
- 如何检测错配账号而不泄露商家私有数据？
- 如果读请求需要近实时 follower 数，成本与上游配额如何变化？
