Nvidia 云维护事件同步平台：双向语义、冲突与 Dashboard 更新

题意与假设

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

• 训练版接入多个云厂商的计划维护、故障开始/更新/恢复事件，展示受影响区域和服务；本地运维人员可确认、备注和绑定内部服务。题目未列具体字段。
• “双向”先拆成两个问题：厂商状态进入本地，以及本地状态是否能回写厂商。只有厂商提供可写 API 且授权时才实现回写；否则本地确认与备注只保存在自有平台，不伪称厂商已同步。
• 示例目标是事件进入本地后 2 分钟内可见；这个 SLO、租户量和 QPS 都是训练假设，需在面试中确认。

解题路线

1. 为每个 provider 建适配器：优先接 webhook，辅以带游标的轮询和定期全量对账。原始事件先存不可变 inbox，再规范化 provider_id、external_event_id、版本、状态、影响范围与时间；保留原文供排错。
2. 以 (provider_id,external_event_id,version) 做摄入幂等键；同一个事件多次更新时采用厂商版本或可信事件时间排序，不能仅凭到达顺序覆盖较新状态。内部事件有自己的 ID，并维护外部 ID 映射。
3. Dashboard 查询读取已物化的当前状态与变更历史，按租户权限过滤。厂商 planned→active→resolved 的变化触发受影响内部服务匹配与告警；重复事件不得重复通知。
4. 若厂商支持回写，把本地可写字段放 outbox，并由单独 worker 调用厂商 API；失败重试、速率限制和死信处理独立于入站。字段所有权表规定厂商掌握外部状态，本地掌握确认/备注，避免两个方向相互覆盖并形成回环。
5. 监控每个 provider 的摄入延迟、游标停滞、解析失败、去重率、对账差异与 outbox 积压。oncall 先识别是厂商源头无更新、传输故障还是本地规范化/展示故障，再重放 inbox 或游标补拉。

手动走一遍

厂商事件 E42 的版本 3 报告 us-east 计划维护，平台摄入后在自有 dashboard 显示 planned；版本 4 报 active 并触发一次内部服务告警。网络重试又送来版本 3，幂等与版本检查阻止倒退。运维人员确认并写备注：若厂商无回写 API，备注只更新本地视图；若有 API，outbox 记录待回写及最终结果。

规模与取舍

P 个厂商、每秒 E 条事件：正常摄入与状态更新约 O(E)，事件映射与当前状态存储 O(H+M)，H 为保留的历史事件量、M 为当前事件数。端到端延迟由厂商发布、webhook/轮询周期、队列积压和 dashboard 缓存共同决定；2 分钟训练目标需要逐段预算和告警。

易错点与追问

容易失分的边界

• 把“厂商 → 自有 dashboard”直接当作可回写厂商，忽略厂商 API 权限及字段所有权。
• 按消息到达顺序做 last-write-wins，迟到旧版本把 resolved 覆盖回 active。
• 轮询只记最新一页而不存游标或不对账，服务重启和分页变化会漏事件。
• 重复 webhook 触发重复告警或回写回环；要以事件版本与通知键做幂等。

继续深挖

• 若厂商无稳定版本号，可用事件时间、内容哈希和周期对账，但需要说明同时间冲突的保守规则。
• 若多个 provider 同时影响同一内部服务，保留外部事件来源并在内部聚合展示，不能把不同故障误合并为单一事件。
• 若要求秒级更新，比较 webhook、长轮询和定期轮询的可用性、成本与故障恢复。