What is a 'sloppy quorum' in a quorum-replicated store like Amazon Dynamo or Cassandra, how does it differ from a strict quorum, and what consistency guarantee do you give up by using one?

## The strict quorum it relaxes To understand sloppy quorums you first need the strict quorum they relax. In a strict-quorum system, each key is deterministically mapped (often via consistent hashing) to a fixed set of N 'owner' nodes — the **preference list**. - A write must get W acknowledgments from nodes in that specific preference list. - A read must get R responses from that same list. That is exactly what makes the R+W>N overlap argument valid: both operations draw from the same fixed pool of N nodes. If, during a network partition or a node outage, fewer than W of the designated owners are reachable from the coordinator, a strict-quorum system simply fails the write — it refuses to substitute other nodes, because doing so would break the mathematical guarantee that makes quorums useful in the first place. ## What a sloppy quorum does instead A sloppy quorum takes the opposite stance on availability. Instead of failing the write when too few of the 'correct' owners are reachable: 1. The coordinator picks other healthy nodes in the cluster — any nodes it can reach — and writes the data there instead, counting those acknowledgments toward W. 2. Each such 'borrowed' write carries a **hint**: metadata recording which node was actually supposed to receive this data. This mechanism, **hinted handoff**, means the write still succeeds and the client still gets an ack, even though the data temporarily lives on the 'wrong' nodes. 3. Later, once the intended owner node recovers and rejoins the cluster, the nodes holding hints proactively push (hand off) the data to it, and then discard their temporary copy. The design goal is explicit: Amazon's Dynamo paper introduced this to guarantee that writes are always accepted (the shopping-cart use case prioritized 'always writable' over strict correctness — losing a cart update is worse than briefly serving a stale cart). ## What you give up The cost is precisely the overlap guarantee that R+W>N was built to provide. A strict quorum read still queries R nodes from the fixed preference list — but if a recent write went to sloppy/hinted nodes outside that list (because the real owners were briefly unreachable), the read's fixed preference-list nodes may not have that write yet at all, hint or no hint, until the handoff completes. So the read can return a version older than the latest acknowledged write, something the strict R+W>N argument explicitly promised couldn't happen. In other words, sloppy quorums intentionally trade the deterministic-overlap consistency property for availability during exactly the failure scenarios (partitions, node outages) where a strict system would instead refuse to accept the write at all. This is a direct, concrete instance of the availability side of the CAP trade-off, applied selectively (per-write) rather than as a blanket policy. ## Closing the divergence window Because sloppy quorums create a window of divergence, real systems pair them with repair mechanisms to eventually reconverge state: - **read repair** — when a read's R responses disagree, the coordinator pushes the newest version back to the stale replicas it just saw - **background anti-entropy processes** — e.g. Merkle-tree comparison between replicas run periodically to find and fix divergence that read repair never happened to trigger, since read repair only fixes keys that actually get read Without these, the temporary inconsistency introduced by sloppy quorums could persist indefinitely for cold, rarely-read keys. ## When to turn it on Operationally, the decision to enable sloppy quorums is a knob, not a fixed property of the algorithm — Cassandra exposes it as a per-operation config, sometimes as a 'write to any available replica' fallback behavior, while Dynamo enabled it as a core design default. | Workload | Usual stance | |---|---| | Teams that need strict linearizable-ish reads-after-writes (e.g. a financial ledger balance) | generally disable sloppy quorums and accept write failures during partitions | | Teams optimizing for 'never reject a write' (e.g. a shopping cart, a like counter, presence/session data) | accept the temporary staleness window in exchange for never bouncing a client's request during a transient outage |