Concepts
Quorum reads and writes (N/R/W)
Intuition
Say you keep three copies of an important note in three different drawers so that losing access to one drawer doesn't lose the note. You could require someone to check all three drawers before believing what the note says, but that's slow and fails completely if even one drawer is jammed. Instead, you decide in advance how many drawers must agree before you trust a reading, and how many drawers must be updated before you consider a write "done" — you get to choose those numbers, trading a bit of certainty for a lot of speed and resilience to a jammed drawer or two.
How it works
Dynamo replicates each key onto N nodes (the preference list derived from consistent hashing) and lets operators independently tune R, the number of replicas that must respond to a read, and W, the number that must acknowledge a write, without requiring all N to participate in every operation. Setting R+W greater than N produces overlapping read/write quorums, which makes it likely a read touches at least one replica holding the latest write and so reduces the chance of returning stale data; setting R+W at or below N favors lower latency and higher availability at the cost of more possible staleness. Dynamo's reported production default is N=3, R=2, W=2. Crucially, a write does not require all N preferred nodes to be reachable: if one is down, Dynamo falls back to a "sloppy quorum" by sending the write to another node further down the ring, tagging it with a hint recording the node it was really meant for (hinted handoff); once the original replica recovers, the hinted node forwards the data to it. This is what lets Dynamo remain always-writeable through node failures or network partitions, at the cost of temporarily divergent replicas that other mechanisms (read repair, anti-entropy) must later reconcile.
In practice
This N/R/W tunability is the mechanism Dynamo, Cassandra, Riak, and Voldemort all expose to let each application pick its own point on the availability/consistency spectrum per operation — a shopping cart write can favor R+W≤N for always-on availability, while a use case that can't tolerate staleness can set R+W>N. Reach for tunable quorums plus sloppy quorum/hinted handoff whenever a system must keep accepting writes during partial failures or partitions and can tolerate resolving any resulting inconsistency after the fact rather than blocking on it.
Use it in a design
Practice the cases that rely on this concept in the System Design school.