Rippling 邮件包裹追踪 Widget：抽取运单号与保持状态新鲜度

题目重点：在邮件摄入与收件箱读路径都只能增加少量延迟的约束下，异步抽取、去重、追踪状态与展示 active shipments。

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

‘少量延迟’没有毫秒指标，设计先以不阻塞邮件入库和 inbox 首屏为原则；实际 P95 预算需由面试官确认。
训练版仅在用户同意/产品权限允许时解析邮件，抽取候选 tracking ID，再按 carrier+tracking_number 去重；误报必须允许用户移除。

邮件主摄入事务只持久化邮件并发轻量事件；异步 worker 提取候选承运商/运单号、置信度及邮件引用，避免把模型/外部承运商 API 调用放在邮件到达同步路径。
以 user+carrier+tracking_number 为 shipment identity，合并多封确认/更新邮件；低置信度候选不自动展示或标待确认，删除邮件、取消订阅和隐私撤回要影响索引与缓存。
状态更新通过承运商 webhook 优先、轮询兜底，按状态版本/事件时间避免旧回执覆盖新状态；设不同阶段的刷新 TTL、退避与限额，记录 last_checked_at 和 freshness。
Inbox 读路径从用户预计算 active shipment 小集合读取，无外部 API 网络调用；缓存未命中展示邮件主内容和可降级 widget，异步补数据。Delivered/Cancelled 的移出规则与多包裹订单需先确认。
量测邮件摄入附加耗时、inbox 首屏 P95、抽取 precision/recall、状态过期率、供应商错误、用户误报反馈；明确错误状态和重试上限。

用户收到订单确认与发货两封邮件，都含同一运单号；异步抽取得到相同 carrier+number，只建立一个 shipment。收件箱从本地状态展示‘运输中，状态更新于 10:03’，承运商 API 超时不拖慢邮件列表；下次重试成功再更新。

摄入抽取量随邮件数 M 增长；每用户 inbox 读通常只取活跃包裹数 S，目标 O(S) 输出和小量本地查询。外部轮询成本约活跃包裹数×刷新频率，须做去重、批量和状态驱动调节；题目不给具体 M/S/QPS。