Two Targets One Write
When migrating to a new database, the dual write pattern has the application write each change to both the old and new store. This keeps the new store current while the old one stays authoritative until cutover.
The Appeal
- The new store fills with live data as it arrives, not just a one time copy.
- Reads can be slowly shifted to the new store and compared.
- It avoids a long freeze for a single bulk copy.
The Consistency Trap
Dual writes are deceptively dangerous because the two writes are not atomic. If the write to the old store succeeds but the new one fails, the stores diverge. A crash between the two writes leaves the same gap. There is no transaction spanning both systems.
Teams mitigate this by writing to one store, then publishing a change event that a consumer applies to the other, turning two writes into one durable write plus a reliable async copy. This is often why change data capture is preferred over raw dual writes.
Key idea
The dual write pattern writes to old and new stores together but the two writes are not atomic, so a partial failure causes drift, which pushes teams toward change data capture instead.