Why Write Conflicts Happen

The Root Cause

In a single-leader system, all writes are serialized through one node. The primary processes write A, then write B. There is a defined order — no conflict is possible. Consistency is guaranteed by serialization.

The moment you introduce a second writer — a second leader in a multi-leader system, or any node in a leaderless system — you lose guaranteed ordering. Two clients can now simultaneously update the same record on different nodes. Those updates are locally valid on their respective nodes. When the nodes replicate to each other, they arrive at an irreconcilable state: two different values for the same field, both with legitimate provenance. The system must choose what to do.

The Scale of the Problem

Write conflicts are not edge cases. In a globally distributed multi-leader system serving millions of users, two users updating the same record simultaneously is a statistical certainty. Every record that can be updated must have a defined conflict resolution strategy — implicit or explicit. Systems that don't define one typically inherit LWW by default, which silently discards data without alerting engineers or users.

Conflict Detection

Before resolving a conflict, the system must detect one. Two mechanisms:

• Last-Write-Wins (implicit): No explicit detection — the system simply overwrites the earlier write. No conflict is ever surfaced. Simple but lossy.
• Version vectors / vector clocks: Each write carries a version vector — a map of node ID to sequence number. By comparing version vectors, the system can determine whether two writes are causally ordered (one happened before the other — no conflict) or concurrent (neither preceded the other — true conflict requiring resolution).