Quorum systems are the math behind 'tunable consistency' in Dynamo-style databases (Cassandra, Riak, Scylla). R+W>N gives you strong consistency without consensus; sloppy quorum trades it for availability. Knowing the knobs lets you pick the right setting per query.
The basic rule
N = replication factor. R = read quorum (acks needed for a read). W = write quorum (acks for a write). If R+W>N, every read sees the latest write — guaranteed by pigeonhole, no consensus needed. Cheap strong consistency.
Common settings
R=W=QUORUM, N=3 → R+W=4>3, strongly consistent, tolerates 1 node down. R=W=ONE → lowest latency, eventually consistent, available even with 2 down. R=ALL, W=ONE → read-strong write-fast (rare). Each combo is a different point on the consistency/availability curve.
Sloppy quorum
Strict: writes must hit W of the N primary replicas. Sloppy: if some primaries are down, write to replacement nodes (hinted handoff) — counts toward quorum. Higher availability; relaxes the R+W>N guarantee until hints replay.
Latency vs consistency
Higher quorum = more node hits = higher latency (slowest acceptable wins). LOCAL_QUORUM keeps the latency local to one DC. EACH_QUORUM gives global consistency at the cost of cross-DC latency. The knob is per-query; use it.
Production sizing
N=3 is the default-good answer. Larger N (5) costs more but tolerates more failures. R=W=QUORUM as the workhorse. Lower for non-critical writes; higher for billing and auth. Re-evaluate per workload, not blanket cluster setting.