割接期间的 dual-write 窗口风险

dual-write 窗口意味着同一条 outbound 消息可能同时打到新旧两个 webhook endpoint——只要 cutover 未关闭。这不是安全网，而是 debit 与 DLR 风险。财务看到双行；ops 看到双份 delivered 时钟；买家看到与记忆中发送不一致的 ledger。

IOSOR cutover 把 dual-write 当作有退出负责人的计时例外。若两个 endpoint 在无幂等故事下保持 Live，hold 与账单会在整周发票周期漂移。

流量拆分前命名 dual-write 窗口

在第二个 endpoint 接收 production 事件前写明开始、结束与退出负责人。把窗口写进割接工单，避免 DLR 紧张时开发「悄悄延长」。未命名窗口会变成永久分叉。

列出允许 dual-write 的事件类型（仅 DLR，或 send+DLR）。禁止组合写在工单标题，而不是首次双扣后的走廊闲聊。

两个 endpoint Live 时对资金事件去重

把每个 webhook payload 映射到财务可引用的幂等键。拒绝或合并重复的 delivered/failed，使钱包每条 message id 只开一个 hold、只关一次 debit。重试可以；双份资金不行。

若新旧 endpoint 对最终状态争执，冻结 message id 并导出两边 payload。不要让发票周把「两边」对成两行可计费记录。

用硬退出时钟限制窗口

设定 dual-write 最长时长，以及时钟归零时关掉旧 endpoint 的 kill switch。只能用书面变更和新时钟延长——绝不把两个 URL 留在密钥库「到下个冲刺」。

把时钟与第二 endpoint 交接清单配对，让 ops 知道哪个 URL 成为唯一所有者。一句「我们再看看」不是退出。

割接后证明单一 ledger 所有者

旧 endpoint 停止后，导出 dual-write 时段与之后第一个安静小时的 hold-versus-debit。确认每条 message id 只有一个钱包所有者。然后才在工单标记 cutover complete。

若双行仍在，提高试点量前重开冻结清单。dual-write 残留是 ops 缺陷，不是定价争论。

相关运维路径

• 第二个 Webhook 端点：事件交接
• 幂等、重试与资金安全
• 账单周钱包对账：单次导出掌握资金预留、扣款与退款

从 IOSOR 开始

命名 dual-write 时钟与负责人，为资金事件接上幂等，并在旧 URL 上设置 kill switch。让一条走廊穿过窗口，导出双风险行，在发票周关闭前退出到单一 endpoint。 割接前把 spend 证明和买家文案清洗写进同一份密封地图，财务签字后再换 Live 密钥。 kill 时刻一到就关掉双写，不要用聊天把窗口拖长。 割接前把 spend 证明和买家文案清洗写进同一份密封地图，财务签字后再换 Live 密钥。 kill 时刻一到就关掉双写，不要用聊天把窗口拖长。

IOSOR 要点

dual-write 是计时风险，不是安慰毯：同一条消息两个 webhook 可能加倍 DLR 与 debit。限制窗口，用幂等去重资金，并在宣称 cutover 完成前证明单一 ledger 所有者。