In multi-leader replication, multiple nodes act as leaders, and each can accept writes independently. Unlike Kafka’s partitions (which are strictly assigned to a single leader), multi-leader setups don’t partition the consistent hashing space among leaders. Instead:
How It Works
-
Writes to Any Leader:
- A client can write to any leader in the system. Each leader replicates the write to its followers and synchronizes with the other leaders.
-
Conflict Resolution:
- Since writes can happen simultaneously to multiple leaders, conflicts may occur (e.g., two leaders updating the same key). These conflicts are resolved using strategies like:
- Last-Write-Wins (LWW): The write with the latest timestamp overwrites others.
- Application Logic: Developers define custom merge logic for conflicts.
- Since writes can happen simultaneously to multiple leaders, conflicts may occur (e.g., two leaders updating the same key). These conflicts are resolved using strategies like:
-
Use of Consistent Hashing:
- Multi-leader systems often use consistent hashing to route requests to the closest or least-loaded leader. However, leaders are not strictly tied to specific partitions—they replicate all changes to ensure data consistency.
Examples
- DynamoDB Global Tables: Writes can happen in any region (leader) and are asynchronously replicated across all regions. Conflict resolution ensures eventual consistency.
- Couchbase: Each node can serve as a leader for writes, with conflict resolution handled by Last-Write-Wins.