Leaderless Replication
A replication approach where any node can accept reads and writes. Uses quorum reads/writes for consistency. Cassandra and DynamoDB use this model.
What is Leaderless Replication?
In short
Leaderless replication is a database replication model where there is no single primary node; any replica can accept both reads and writes, and the system uses quorum rules across multiple nodes to keep the data consistent enough. Amazon DynamoDB and Apache Cassandra popularized this design, which trades strict consistency for high availability and tolerance of node failures.
What it is
In most replicated databases, one node is the leader. Every write goes to the leader first, then the leader copies the change to follower replicas. This is leader-based (or primary-replica) replication, and it is what Postgres streaming replication and MySQL use by default.
Leaderless replication throws out the idea of a leader entirely. Every replica is equal. A client can send a write to any node, and it can read from any node. The model came from Amazon's 2007 Dynamo paper and shows up today in Cassandra, ScyllaDB, Riak, and DynamoDB.
Because there is no single node that must be online to accept writes, the cluster keeps working even when several machines are down or unreachable. That availability is the whole point. The cost is that different replicas can briefly disagree about the current value, and the application has to be designed to expect that.
How quorums keep it consistent enough
With no leader to serialize writes, leaderless systems use quorums. You configure three numbers: N is how many replicas hold a copy of each piece of data, W is how many of them must acknowledge a write before it is considered successful, and R is how many must respond before a read is returned.
The rule that gives you fresh reads is W + R > N. With N=3, a common choice is W=2 and R=2. A write is durable once 2 of the 3 replicas confirm it. A read asks 2 of the 3 replicas, and since 2 + 2 is greater than 3, at least one of the replicas you read from is guaranteed to have seen the latest write. The client compares the responses, by version number or timestamp, and keeps the newest one.
Writes are usually sent to all N replicas in parallel; the request just returns as soon as W of them answer. Nodes that were down catch up through two mechanisms: read repair, where the client writes the fresh value back to a stale replica it noticed during a read, and anti-entropy background processes that compare replicas and reconcile differences using structures like Merkle trees.
When to use it and the trade-offs
Reach for leaderless replication when availability and write throughput matter more than reading your own writes instantly. Shopping carts, sensor data, activity feeds, session stores, and event logging all tolerate brief disagreement well. If a cart line item shows up a second late, nobody cares; if the checkout page is down, you lose money.
The big trade-off is consistency. Quorums give you strong-ish reads only on average. With concurrent writes to the same key, two replicas can end up with conflicting values, and the database has to resolve them. DynamoDB and Cassandra default to last-write-wins by timestamp, which can silently drop data; Riak can keep both versions as siblings and hand the conflict back to your application to merge.
You also lose easy transactions and ordering guarantees across keys. Sloppy quorums, where a write lands on whatever N nodes are reachable rather than the canonical N, boost availability further but can return stale reads even when W + R > N. Plan for clock skew, plan for conflict resolution up front, and do not assume a successful quorum write means every replica is current.
Where it is used in production
Amazon DynamoDB
Built on the original Dynamo design; uses replication across availability zones with tunable eventually consistent and strongly consistent reads.
Apache Cassandra
Fully leaderless ring of equal nodes with per-query tunable consistency levels like ONE, QUORUM, and ALL, plus read repair and hinted handoff.
Riak
Open-source Dynamo-style store that exposes N, R, and W directly and can return conflicting siblings for the app to merge.
ScyllaDB
Cassandra-compatible C++ rewrite that keeps the leaderless quorum model while pushing higher throughput per node.
Frequently asked questions
- What is the difference between leaderless and leader-based replication?
- Leader-based replication routes every write through one primary node that orders changes and copies them to followers, giving simple consistency but a single point for writes. Leaderless replication has no primary; any node accepts reads and writes, and quorums plus background repair keep replicas in sync. Leaderless wins on availability and write tolerance, leader-based wins on simplicity and strong ordering.
- What does W + R > N actually guarantee?
- It guarantees that the set of replicas you read from overlaps with the set that acknowledged the latest write by at least one node, so a read sees the most recent successful write. With N=3, W=2, R=2 you get this overlap. It does not protect you from concurrent conflicting writes or from sloppy quorums, where the guarantee can break.
- How does leaderless replication handle conflicts?
- When two clients write the same key concurrently, replicas can hold different values. Most systems use last-write-wins, picking the value with the highest timestamp, which is simple but can drop data under clock skew. Riak can instead store both as siblings and use version vectors so the application merges them. Choosing a conflict strategy is a required design decision, not a default to ignore.
- Is leaderless replication the same as eventual consistency?
- They are related but not identical. Leaderless replication is the architecture (no primary, quorum reads and writes). Eventual consistency is a guarantee level: if writes stop, all replicas eventually converge. A leaderless system with low R and W is eventually consistent, but tuning W + R > N gives stronger read freshness than plain eventual consistency.
- Why did Amazon invent this model for Dynamo?
- Amazon needed the shopping cart and other core services to stay writable during data center failures, network partitions, and routine node maintenance. A single leader becomes a bottleneck and a failure point. By making every node able to accept writes and reconciling later, the 2007 Dynamo design kept the storefront available even when parts of the infrastructure were down.
Learn Leaderless Replication hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
See also
Related glossary terms you might want to look up next.
Quorum
The minimum number of nodes that must agree for a read or write to succeed. With N replicas, W+R > N ensures overlap between write and read sets for consistency.
Replication
Keeping copies of the same data on multiple servers. Improves read performance and provides fault tolerance if one server goes down.
Eventual Consistency
A consistency model where updates propagate asynchronously and all replicas will eventually converge to the same value. Trades immediacy for availability.
Database Partitioning
Dividing a large table into smaller, more manageable pieces while keeping them in the same database. Sharding is partitioning across servers.
Read Replica
A copy of your database that handles read queries, reducing load on the primary database. Writes still go to the primary and replicate out.
Write-Ahead Log
A technique where changes are written to a log before being applied to the database. Ensures durability and crash recovery.