Designing Data-Intensive Applications
Ch. 5

Leaderless Replication

Dynamo-style systems let any replica accept writes and use quorums to detect inconsistency.

Leaderless replication (pioneered by Dynamo) removes the single-leader bottleneck. Any node can accept writes. On read, the client queries multiple replicas and reconciles versions. Quorum rules balance consistency against availability.

Diagram
In practice

Amazon DynamoDB lets you tune W and R per request — R=2, W=2 with N=3 is a common production setting. Apache Cassandra uses tunable consistency (QUORUM, ONE, ALL). During a partition, sloppy quorums and hinted handoff keep writes flowing to healthy nodes.

Stripe at scale

Payment session state and idempotency records use Dynamo-style quorum writes so any replica can accept a retry without a single leader bottleneck. Tunable R/W per request trades latency for consistency.

typescript — Quorum read and write
// DynamoDB-style quorum: W + R > N ensures read/write overlap
const N = 3, W = 2, R = 2;
async function write(key: string, value: VersionedValue) {
  const nodes = pickNodes(key, N);
  await Promise.all(nodes.slice(0, W).map((n) => n.put(key, value)));
}
async function read(key: string) {
  const nodes = pickNodes(key, N);
  const versions = await Promise.all(nodes.slice(0, R).map((n) => n.get(key)));
  return versions.sort((a, b) => b.version - a.version)[0];
}
Key Takeaways
  • Clients write to multiple replicas in parallel (W replicas).
  • Reads contact R replicas and pick the most recent version by version number.
  • Quorum condition W + R > N ensures overlap between read and write sets.
  • Sloppy quorums and hinted handoff maintain availability during partitions.
  • Version vectors detect concurrent writes that need merging.
  • Amazon DynamoDB, Cassandra, and Riak follow Dynamo-style quorum design.
quorumDynamoDBCassandraleaderlessversion vectorsloppy quorum