How Single-Leader Replication Handles Write Conflicts: Strategies and Insights

Write Conflicts in Single-Leader Replication

A write conflict occurs when multiple users attempt to modify the same data concurrently. Exclusive (private) data without uniqueness constraints does not conflict, but if a uniqueness constraint is applied, conflicts can arise. Shared data—such as a meeting‑room reservation—inevitably faces write conflicts because only one user can occupy the resource at a given time.

Leader‑Based Replication Model

For exclusive data without uniqueness constraints, the leader ensures linearizable writes: each client operation follows the total order on the leader, and followers replicate the writes in the same order, guaranteeing consistency.

When exclusive data has a uniqueness constraint, the storage engine creates a unique index and uses locking or MVCC to enforce it. The leader still replicates writes to followers in order, and the engine logs changes (WAL) before persisting them, ensuring durability.

Asynchronous replication introduces latency. If a user writes after the leader’s log is recorded but before it is persisted, a leader failure requires followers to replay the WAL to maintain data integrity.

Shared Data Conflict Handling

Shared resources can be non‑overwritable (e.g., a time‑slot reservation) or overwritable (e.g., collaborative document editing). For non‑overwritable resources, three common solutions are:

Apply a uniqueness constraint to the time‑slot resource.

Use a bitmap representation where each bit indicates occupancy, updating via CAS.

Employ a Last‑Write‑Wins (LWW) strategy with a globally ordered, monotonically increasing counter; higher counters win, causing lower‑counter writes to fail.

Overwritable Shared Resources (Collaborative Editing)

Simple locking prevents concurrent edits, which is unsuitable for real‑time collaboration. Multi‑version control allows each user to edit independently, generating separate versions that must be merged. Conflicts are resolved manually, similar to Git branching and merging, or automatically using LWW, though automatic LWW can cause data loss in collaborative scenarios.

Automatic conflict resolution approaches, such as distributed leader‑based replication algorithms, rely on version numbers and total ordering to decide the winning write, but they must be carefully designed to avoid losing user edits.

Summary

In single‑leader replication, exclusive data without uniqueness constraints experiences no write conflicts. Exclusive data with uniqueness constraints, shared non‑overwritable data, and shared overwritable data all encounter conflicts, but they can be mitigated through unique indexes, bitmap locking, LWW ordering, and multi‑version control. Future discussions will explore multi‑leader and leaderless replication, where versioning and ordering become even more critical.