Dual-write window risk during cutover

A dual-write window means the same outbound message can hit two webhook endpoints — old and new — while cutover is unfinished. That is not a safety net; it is a debit and DLR hazard. Finance sees twin rows; ops sees twin “delivered” clocks; buyers see a ledger that no longer matches the send they remember.

IOSOR cutovers treat dual-write as a timed exception with an exit owner. If both endpoints stay Live without an idempotency story, holds and invoices drift for the whole invoice week. Document the kill criteria in writing before the first parallel debit so nobody extends the window by chat.

Name the dual-write window before traffic splits

Write the start time, end time, and exit owner before any second endpoint receives production events. Publish the window in the cut ticket so developers do not “extend quietly” when DLR looks nervous. An unnamed window becomes a permanent fork.

List which event types are allowed to dual-write (DLR only, or send+DLR). Forbidden pairs belong in the ticket title, not in a hallway chat after the first double debit.

Deduplicate money events while two endpoints are Live

Map every webhook payload to an idempotency key finance can cite. Reject or merge duplicate delivered/failed events so the wallet opens one hold and closes one debit per message id. Retries are allowed; double money is not.

If the old endpoint and the new endpoint disagree on final status, freeze the message id and export both payloads. Do not let invoice week reconcile “both” as two billable rows.

Cap the window with a hard exit clock

Set a maximum dual-write duration and a kill switch that stops the old endpoint when the clock hits zero. Extend only with a written change and a new clock — never by leaving both URLs in the secret store “until next sprint”.

Pair the clock with a second-endpoint handover checklist so ops knows which URL becomes sole owner. A soft “we will watch it” is not an exit.

Prove one ledger owner after the cut

After the old endpoint stops, export hold-versus-debit for the dual-write hours and the first quiet hour after. Confirm one wallet owner per message id. Only then mark cutover complete in the ticket.

If twin rows remain, reopen the freeze list before raising pilot volume. Dual-write residue is an ops defect, not a pricing debate.

Related ops paths

• Webhook second-endpoint handover
• API idempotency, retries, and money
• Wallet invoice week: hold vs debit

Start with IOSOR

Name the dual-write window, the kill clock, and the single ledger owner in writing before the first parallel debit. Deduplicate money events on both endpoints until the cut, then prove one owner owns every hold and debit after exit.

IOSOR takeaway

Two Live endpoints for one message create double-debit and conflicting DLR risk. Cap the dual-write window with a hard exit clock and one named owner — chat extensions are how money doubles.

Do not leave both endpoints Live past the kill time. Do export the dedupe proof and the post-cut ledger owner before finance signs the cutover.