Resolving Write Conflicts in Multi-Leader Systems

Good to see you again. In the previous lesson, replication lag meant that replicas held different points in one leader’s history. This time the issue is more fundamental: in a multi-leader system, more than one node may accept writes independently. Two leaders can therefore accept incompatible changes before either learns that the other change exists.

The goal is to recognize a genuine write conflict, understand why replicas must converge on a shared result, and choose among prevention, deterministic winners, merging, and application-specific resolution. This is the central trade-off behind multi-leader replication: local write availability and low latency come with responsibility for reconciling concurrent changes.

---

From delayed visibility to conflicting histories

A multi-leader system has several writable replicas, often in different data centers or on clients that can work offline. A local leader accepts a write and later propagates it asynchronously to the other leaders.

That arrangement can be useful:

• A user can write to a nearby data center rather than a distant central leader.
• Multiple leaders can share write load.
• An offline-first application can let a device accept edits before reconnecting.

But it removes the single place where every update can be immediately ordered.

Consider a record whose current title is "A".

1. Client 1 writes "B" to leader 1.
2. At nearly the same time, Client 2 writes "C" to leader 2.
3. Neither client had observed the other client’s update when it made its own write.
4. Both leaders acknowledge their local write.
5. The leaders later exchange replicated changes.

The two writes are concurrent: neither is known to have happened after the other. It does not matter whether their wall-clock timestamps happen to differ by a few milliseconds. What matters is that neither write causally depended on the other.

In a single-leader system, both requests reach one leader, which establishes an order. It may accept one and overwrite it with the other, reject one based on a version check, or run a transaction. In multi-leader replication, each leader has already committed a locally reasonable update before the conflict becomes visible.

This differs from the anomalies in the previous lesson:

Situation	What replicas disagree about	Core problem
Replication lag with one leader	How much of one ordered history they have applied	A read may be stale
Multi-leader conflict	Which of several concurrent histories should determine the result	Writes may be incompatible

---

Why conflict resolution must converge

When each leader receives the remote write, it cannot simply apply operations in arrival order.

Suppose leader 1 sees the writes as:

$$\text{A}\text{ then B}\text{ then C}$$

while leader 2 sees:

$$\text{A}\text{ then C}\text{ then B}$$

If both interpret an update as “set the title to this value,” leader 1 ends with "C" and leader 2 ends with "B". Replication would have delivered the same two writes everywhere, yet the replicas would remain permanently inconsistent.

A multi-leader system therefore needs a convergent resolution rule: once every replica has received the same relevant updates, every replica must compute the same result, regardless of message arrival order.

The rule need not preserve every value. A system can converge by discarding one update. But that is a product decision, not merely a database implementation detail. If a discarded update represented an address change, a payment action, or a medical record correction, convergence alone is not enough.

---

Four broad strategies

A useful way to compare strategies is to ask two questions:

1. Can incompatible writes both be accepted?
2. If so, does the system preserve both users’ information?

1. Detect conflicts synchronously

In principle, a leader can wait until its write has been checked against all other leaders before telling the client that it succeeded. If another leader has an incompatible write, the system can reject or coordinate one of them.

This prevents a conflict from being discovered later, but it gives up much of the purpose of multi-leader replication:

• every write waits for cross-region communication;
• a disconnected leader may be unable to accept writes;
• the system behaves more like a coordinated single-writer design.

Synchronous detection can be appropriate for data that truly must have one globally agreed result before proceeding. It is not a general way to retain offline or geographically local writes.

2. Avoid conflicts by assigning each record a home leader

Conflict avoidance routes every write for a particular record, user, or key to one designated leader. For example, all updates to a customer profile might go to the leader responsible for that customer ID.

The designated leader can serialize those writes, so two leaders do not concurrently edit the same logical object.

Strength	Cost
Simple reasoning for one record	The “home” leader can be far from the user
Prevents many same-record conflicts	A hot record concentrates load
Preserves ordinary single-leader semantics per key	Failover or reassignment can reintroduce conflicts

The last limitation is crucial. If a regional outage forces traffic to a different leader, or if routing configuration changes while old clients are still active, the original assumption may no longer hold. Conflict avoidance reduces the conflict surface; it does not eliminate the need for a fallback policy.

3. Pick a deterministic winner

A system can attach a unique, comparable identifier to every write and retain the write with the highest identifier. Every replica eventually sees the same candidates and applies the same winner rule.

A common form is last write wins (LWW), in which a timestamp determines the winner. Other systems may use a logical sequence, a random unique ID, or a fixed replica-ID tie-breaker.

For the two title updates, the rule might say that "C" wins. Every replica will eventually store "C".

This is operationally attractive because it is automatic and convergent. However, it has an unavoidable semantic cost:

The losing write is discarded.

The word last in last-write-wins can be misleading. A timestamp from different machines does not reliably establish which user action was meaningfully later, especially if clocks are skewed or adjusted. More importantly, even a perfect ordering cannot tell the system whether "B" or "C" was the better business result. It merely imposes a deterministic choice.

Use a winner-takes-all policy when overwriting is genuinely acceptable, such as a frequently refreshed device-presence value. Avoid treating it as harmless for edits where both values may matter.

4. Preserve the alternatives, then merge or resolve them

Instead of immediately discarding a concurrent update, the database can preserve several conflicting versions. The application then resolves them using domain knowledge.

For example, suppose an offline desktop changes Bob’s email address while an offline laptop changes Bob’s mobile number. A sensible application can produce one merged business card containing both changes. By contrast, two edits to the same appointment time may need a human to decide which one reflects the intended schedule.

Apache CouchDB illustrates this approach directly.

CouchDB chooses a deterministic “winning” revision for an ordinary read, so replicas agree on what they display by default. But it keeps the other revision rather than destroying it. The application can fetch all conflicting versions, create a merged document, and explicitly mark the obsolete branches as resolved.

This is a valuable distinction:

• Choosing a displayed winner makes replicas converge.
• Actually resolving the user-level conflict requires preserving and reconciling the meaningful information.

---

When and how to perform resolution

Application-specific resolution can occur at two different times.

Resolve on write

When a replicated change arrives and conflicts with local state, the database invokes a conflict handler. This keeps later reads simple: by the time an application reads the record, there is one resolved version.

The limitation is that this handler usually runs in the background. It must be fast and deterministic; it cannot wait for a person to compare two alternatives. It works well for rules such as:

• merge independent fields;
• take the union of append-only tags;
• retain the highest observed score;
• reject an invalid combination.

Resolve on read

Alternatively, the database returns all conflicting versions to the application. The application may merge them automatically or ask a user to decide, then write the resolved value back.

This retains the maximum information and enables human judgment. The trade-off is added complexity: every reader that encounters an unresolved conflict must be prepared to handle multiple versions.

A collaborative editor provides a useful contrast. If two people edit different parts of a document, merely choosing one entire document version would throw away useful work. Editing systems instead use specialized algorithms, such as operational transformation or CRDTs (conflict-free replicated data types), to merge many small operations into a coherent shared document.

These techniques are not universal conflict solvers:

• A CRDT provides well-defined merge behavior for particular data types, such as counters, sets, maps, or ordered sequences.
• Operational transformation is designed for concurrent edits to ordered content such as text.
• A business rule like “a room cannot be booked twice” still needs an explicit policy or coordination. No generic merge algorithm can infer which reservation should prevail.

---

Choosing a strategy from the meaning of the data

The following guide keeps the comparison practical.

Data or requirement	Suitable direction	Why
A user’s profile is normally edited only by that user	Route writes for that profile to one home leader	Avoids most conflicts simply
A cache-like status value where overwriting is acceptable	Deterministic winner, often LWW	Convergence matters more than retaining every update
An offline contact card where different fields may change independently	Preserve versions and merge fields	Both updates can carry valuable, compatible information
An append-only collection of unique items	A union-style merge or appropriate CRDT	Combining membership is often meaningful
A shared text document	Operational transformation or a text-oriented CRDT	Character-level concurrent edits need specialized logic
A payment, inventory reservation, or exclusive booking	Prevent conflicts through routing or stronger coordination	Silently merging or discarding writes can violate business invariants

The key question is never simply, “What conflict algorithm does the database support?” It is:

If two users make these changes without seeing each other’s work, what outcome is valid, and who is entitled to decide?

If there is only one acceptable answer, prevent concurrent acceptance or coordinate the decision. If both changes may be meaningful, retain enough information to merge them. If one can safely supersede the other, a deterministic winner may be appropriate.

---

Key takeaways

Multi-leader replication lets multiple nodes accept writes independently, but concurrent writes can create incompatible histories. The system cannot safely use replication arrival order because different leaders may receive the same writes in different orders.

• A correct replication design must converge: replicas that have received the same updates must reach the same state.
• Synchronous detection coordinates before acknowledgment, but sacrifices independent local writes.
• Conflict avoidance routes each record’s writes to one leader, though failures and rerouting can undermine that assumption.
• Last-write-wins and other deterministic winner rules converge automatically, but may silently discard meaningful data.
• Retaining competing versions enables application-specific or human resolution; CouchDB’s revision conflicts demonstrate this model.
• Specialized structures such as CRDTs and operational transformation can automatically merge particular kinds of concurrent change, but they do not replace application-level integrity rules.

Next, the course turns to leaderless replication. Rather than selecting one or several leaders, leaderless systems use replicas collectively; you will use quorum parameters to reason about when reads and writes can overlap safely.