In a replicated datastore, each piece of data lives on several nodes so it survives failures. A quorum is the rule that a minimum number of those replicas must respond before a read or a write is considered successful. By requiring overlap between the set of replicas that handle reads and the set that handle writes, the system can guarantee that a read sees the latest write even when some nodes are down.
Amazon’s Dynamo paper makes this idea concrete with three numbers. N is the number of replicas each item is stored on. W is the number of replicas that must acknowledge a write for it to succeed, and R is the number of replicas that must respond to a read. The paper explains that to maintain consistency, R and W are configured so that R + W is greater than N. With that condition, the set of nodes that acknowledged a given write and the set that respond to a later read are guaranteed to overlap in at least one node, so a read can find the most recent value.
The power of the scheme is that R and W are tunable, which lets an operator trade off latency, durability, and consistency. Setting W small makes writes fast and highly available but means fewer replicas have the data immediately; setting R small makes reads fast but risks reading stale data unless R + W exceeds N. The Dynamo authors describe how different services pick different (N, R, W) values to suit their needs, with a common choice being three replicas and quorums of two.
Quorum protocols are a foundational tool for building systems that are both fault-tolerant and consistent. The same R, W, N tuning that Dynamo introduced reappears in systems such as Apache Cassandra and Riak, where it gives applications a dial to choose where they sit between strong consistency and high availability.