What is Multi-Leader Replication and Why Use It?

Multi leader replication (also called active/active or master–master) allows more than one node or Region to accept writes concurrently, unlike single leader replication where all writes must funnel through one serialization point. Each leader applies writes locally first, then propagates those changes to peer leaders asynchronously. This architectural choice fundamentally trades immediate global consistency for availability and low latency local writes. When a user in Tokyo writes to a Tokyo leader and a user in London writes to a London leader at the same time, both writes succeed immediately without waiting for cross Region coordination.

The key benefit is local write latency and availability during network partitions. AWS DynamoDB Global Tables demonstrates this: local writes complete in single digit milliseconds, while cross Region replication happens asynchronously within sub second timeframes under normal conditions. Amazon Dynamo (the internal retail system) used this pattern to meet 99.9th percentile latency targets of a few hundred milliseconds while remaining "always writeable" even during datacenter failures. The system routes read traffic locally as well, often to follower replicas behind each leader, providing read scaling within each Region.

The fundamental tradeoff is pushing the consistency problem from coordination at write time to conflict detection and resolution after the fact. If two leaders accept conflicting writes to the same shopping cart before hearing about each other's updates, the system must detect this conflict and deterministically resolve it so all replicas eventually converge to the same state. This shift means engineering effort moves from managing a single writer bottleneck to building robust conflict management, monitoring replication lag across Regions, tracking conflict rates per keyspace, and ensuring idempotent application of replicated operations.

💡 Key Takeaways

•Each leader accepts writes locally with single digit millisecond latency instead of waiting for global coordination, providing immediate response to users in that Region

•AWS DynamoDB Global Tables achieves sub second cross Region replication under healthy conditions, with actual latency varying by item size and inter Region Round Trip Time (RTT)

•Amazon Dynamo retail system met 99.9th percentile targets of a few hundred milliseconds while remaining available through datacenter failures by using replication factor N=3 with write and read quorums W=2, R=2

•Writes amplify by the number of Regions: 10,000 writes per second of 1 KB items replicated to 3 Regions produces approximately 20 MB per second egress (10k × 1 KB × 2 peers) or 1.7 TB per day in cross Region transfer

•The system trades immediate global consistency for availability, meaning a user writing in Region A might not immediately see their update when reading from Region B without additional read consistency mechanisms

•Engineering complexity shifts from managing single writer bottleneck to conflict detection, resolution strategies, idempotency guarantees, and monitoring replication lag and conflict rates per keyspace

📌 Examples

Amazon Dynamo retail shopping cart: concurrent cart updates from different datacenters create multiple versions; application merges by taking union of cart items to avoid losing user additions

AWS DynamoDB Global Tables: a profile update written in us-east-1 with 5ms latency replicates to eu-west-1 in approximately 80ms to 150ms depending on network conditions and item size; concurrent updates resolved by last writer wins (LWW) using service generated timestamps

Google Docs style collaboration: each client acts as a leader for local keystrokes with under 50ms local echo; operations propagate across continents in 70ms to 200ms and converge using Operational Transformation without requiring global locks

← Back to Multi-Leader Replication Overview