In this lesson, you will learn how to identify conflicts in multi-leader replication environments and implement resolution policies to ensure your data eventually converges.
The Challenge of Concurrent Writes
In a multi-leader setup, every node can accept write requests independently. While this provides excellent write availability and low latency for geographically distributed users, it introduces the write conflict problem. If two users update the same record at the same time on different leaders, the system enters a state of divergence.
Consider a shared document metadata store:
- Leader A receives:
UPDATE users SET status = 'active' WHERE id = 1; - Leader B receives:
UPDATE users SET status = 'suspended' WHERE id = 1;
Without a mechanism to handle this, the two leaders will never agree on the final state, breaking the consistency guarantee.
Implementing Resolution Policies
To reach convergence, the database must execute a conflict resolution policy during the asynchronous replication process. Here are three common strategies:
- Last Write Wins (LWW): Every write is timestamped. When the conflict is detected during replication, the system compares timestamps and keeps the one with the latest value. While simple, this is prone to data loss if clocks are not perfectly synchronized.
- Version Vectors (Causal Ordering): Each node keeps a counter for the record. If the system detects that a version is a "descendant" of another, it keeps the newer one. If they are concurrent (neither is an ancestor of the other), the system flags a conflict for application-level resolution.
- Application-Defined Logic: The database stores both versions and forces the application to reconcile them upon the next read. For example, a shopping cart might perform a "union" of both updates, ensuring items added on both nodes are preserved.
Conflict Detection via Metadata
To identify these conflicts, databases typically attach a version identifier or "Vector Clock" to the row. When a node receives a change from a peer, it inspects this metadata. If the incoming change conflicts with the local version, the pre-defined policy is triggered immediately before the update is applied to the local storage engine.
Key Takeaway: Because multi-leader architectures allow concurrent writes to the same data, you must implement automated conflict resolution policies or application-level logic to ensure that all replicas converge to a single source of truth.