NOTE
4.1 Multi-Leader Replication
Why multiple leaders are useful across regions or offline-capable systems, and how concurrent writes create conflicts that require prevention, detection, or resolution.
This is a historical learning note and may contain outdated or incomplete understanding.
1. What Is Multi-Leader Replication?
Multiple leaders can independently accept writes. Each leader replicates its changes to peers, which in turn propagate the changes to their local followers or storage.
2. When Is It Useful?
- multiple geographic regions need local write latency;
- devices or sites must continue writing while temporarily disconnected;
- migration or integration workflows need more than one writable origin.
3. The Central Problem: Write Conflicts
Two leaders can accept concurrent updates to the same logical item before either sees the other’s write. Both writes may be locally successful, so the system needs an explicit conflict policy.
3.1 Avoid Conflicts
Route all writes for the same entity or user to the same leader. This reduces conflicts but becomes harder when ownership moves or a region fails.
3.2 Detect and Resolve
Possible policies include:
- last-writer-wins using a well-defined ordering, with the risk of losing concurrent writes;
- optimistic version checks that reject writes based on stale versions;
- preserve multiple concurrent values and resolve them at read time;
- domain-specific merge logic, such as set union or application-level conflict resolution.
Timestamp ordering and optimistic version checks are different mechanisms and should not be conflated.
4. Trade-off
Multi-leader replication improves local-write availability and geographic independence, but conflict handling becomes part of the application’s correctness model.