The Dual-Write Race — Two Systems, Two Orders (Figure 12-4) Diagram

No single system can serve every need: an OLTP database for requests, a full-text index for search — each keeps its own copy of the data
Dual writes: the application code explicitly writes to each system on every change — first the database, then the search index
Each system has its own leader and neither follows the other, so there is no single server that decides the order of writes
Two clients concurrently update item X: client 1 sets it to A, client 2 sets it to B

Because of unlucky timing, the four writes interleave
The database sees client 1's write first and client 2's second, so its final value is B
The search index sees client 2's write first and client 1's second, so its final value is A
No error occurred anywhere — both systems accepted both writes successfully

The two systems are now permanently inconsistent; one value silently overwrote the other
Without a concurrency detection mechanism such as version vectors, concurrent writes are never even noticed
If one write fails while the other succeeds the systems diverge too: making them both-or-nothing is the atomic commit problem (2PC), which is expensive to solve
The fix is to give the write path a single ordering authority — e.g. change data capture from the database log (next figure)