Риск dual-write окна при cutover

Dual-write окно значит: одно outbound-сообщение может попасть в два webhook-endpoint — старый и новый — пока cutover не закрыт. Это не safety net, а hazard для debit и DLR. Финансы видят twin-строки; ops — twin-часы «delivered»; buyer — ledger, который больше не совпадает с отправкой, которую они помнят.

Cutover на IOSOR считает dual-write временным исключением с exit-owner. Если оба endpoint остаются Live без idempotency-истории, hold и invoice плывут всю invoice week. Зафиксируйте критерии kill письменно до первого параллельного списания — окно нельзя продлевать в чате.

Назовите dual-write окно до разделения трафика

Зафиксируйте start, end и exit-owner до того, как второй endpoint получит production-события. Опубликуйте окно в cut-тикете, чтобы developers не «тихо продлевали», когда DLR нервничает. Безымянное окно становится постоянным fork.

Перечислите, какие типы событий можно dual-write (только DLR или send+DLR). Запрещённые пары — в заголовке тикета, не в hallway-чате после первого double debit.

Дедупьте money-события, пока Live два endpoint

Свяжите каждый webhook payload с idempotency-ключом, который могут цитировать финансы. Reject или merge дублей delivered/failed, чтобы кошелёк открывал один hold и закрывал один debit на message id. Retries допустимы; double money — нет.

Если старый и новый endpoint спорят о финальном статусе, заморозьте message id и выгрузите оба payload. Не давайте invoice week сверить «оба» как две billable строки.

Ограничьте окно жёсткими часами выхода

Задайте максимальную длительность dual-write и kill switch, который гасит старый endpoint в ноль часов. Продлевайте только письменным change и новыми часами — никогда оставляя оба URL в secret store «до следующего спринта».

Свяжите часы с чеклистом handover второго endpoint, чтобы ops знал, какой URL становится sole owner. Мягкое «посмотрим» — не exit.

Докажите одного владельца ledger после cut

Когда старый endpoint остановлен, выгрузите hold-versus-debit за часы dual-write и первый тихий час после. Подтвердите одного владельца кошелька на message id. Только потом отметьте cutover complete в тикете.

Если twin-строки остаются, снова откройте freeze-лист до роста пилотного объёма. Остаток dual-write — дефект ops, не спор про pricing.

Связанные пути

• Handover второго webhook-endpoint
• API idempotency, retries и деньги
• Invoice week кошелька: hold vs debit

Начните с IOSOR

Назовите dual-write окно, kill-часы и единственного владельца ledger письменно до первого параллельного списания. Дедупьте money-события на обоих endpoint до cut, затем докажите, что после выхода один владелец держит каждый hold и debit.

Итог IOSOR

Два Live endpoint на одно сообщение — риск двойного списания и конфликтующих DLR. Ограничьте dual-write окно жёсткими часами выхода и одним именованным владельцем: продления в чате — как деньги удваиваются.

Не оставляйте оба endpoint Live после kill. Экспортируйте proof дедупа и владельца ledger после cut до подписи finance.