We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Distributed Systems Core
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Distributed Systems Core
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
You learned about quorums in the quorum lesson. W + R > N guarantees that reads overlap with writes. But strict quorums have a hard requirement: the W nodes that acknowledge a write must be the N designated replicas for that key. If two of those three designated replicas are down, the write fails. Strict , strict failure.
Amazon's Dynamo paper asked a provocative question: what if we relaxed that rule? What if a write could go to any W healthy nodes in the cluster, not just the designated replicas? The write still reaches W nodes (so we have redundancy), but some of those nodes might not be the "correct" homes for that data.
This is a sloppy quorum. It's the difference between "only the three assigned doctors can treat this patient" (strict) and "any three available doctors can treat this patient" (sloppy). The sloppy version keeps the hospital running when assigned doctors are unavailable.
Sloppy quorums are the reason Cassandra and DynamoDB can maintain high write availability during partial outages. They're also the reason these systems can't guarantee strict consistency, because the nodes holding the data might not be the ones that a reader checks.
In a strict with N=3, a key K is assigned to nodes A, B, C on the consistent hash ring. A write to K requires W=2 of those three specific nodes.
In a sloppy quorum, if B is down, the write goes to A and D (the next node on the ring after C). D stores the data with a hint: "this belongs to B." When B recovers, D hands the data off (hinted handoff).
| Scenario | Strict Quorum | Sloppy Quorum |
|---|---|---|
| All nodes up | Write to A, B (W=2 of ) | Write to A, B (same) |
| B is down | Write fails (only A available from ) | Write to A, D (with hint for B) |
| B and C down | Write fails entirely | Write to A, D (hint for B), E (hint for C) |
The trade-off is precise: A sloppy quorum guarantees that W nodes store every write (durability), but does NOT guarantee that a subsequent quorum read will see it. A reader querying nodes A, B, C won't find the write that's on D. This is why sloppy quorums provide eventual consistency, not strong consistency.
Dynamo's "always writeable" design: Amazon chose sloppy quorums because for a shopping cart, rejecting a write (user can't add to cart) is worse than serving slightly stale data. The write always succeeds, even if the "correct" replicas are unavailable.