Dual Write
Writing the same change to both the old and new stores during a migration, and the reconciliation that makes it trustworthy.
The standard middle phase of a zero-downtime data migration: the application writes to both stores, reads continue from the old one, and the new one is validated until it can take reads.
The problem is that two writes are not atomic. One can succeed and the other fail — because of a crash, a timeout, or a validation difference — and the stores silently diverge. Care does not fix this; it is a property of doing two things.
Three ways to make it trustworthy:
Change data capture instead of dual write. Write to the old store only, and replicate to the new one from its log. One write, no divergence, at the cost of the new store lagging.
An outbox. Write the business change and an intent record in one transaction, and let a relay apply it to the second store. Atomic, at-least-once, eventually consistent.
Continuous reconciliation. Accept that divergence happens and run a job that compares and repairs, with the divergence rate as a monitored metric and a stated threshold for cutover.
Whichever is chosen, the cutover criterion should be a measured divergence rate over a period that includes a month-end — not a date.