Ризик 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.