Scalable Human Blog

• To start, lets consider the write to be successful when it is only processed by only 2 of the 3 replicas ✅
  • What if 1 of the 3 replicas accepted the write… How far can we push this 🤔
  • If we know every write guaranteed out of 2 of the replicas that means 1 replica could be stale 😵
• Therefore, if we read from at least 2 replicas at least we know that 1 replica of the two is update to date 💡
  • If the 3rd replica is down or slow to repond
    • Reads can continue returning up to date values

Illustrate the Quorum Variables

• W = Minimum write nodes ✍️
• R = Minimum read nodes 📖
• N = Nodes in the quorum group 📚

Summary of Quorum

• More generally if there are N replicas 📚
• Every write must be confirmed by W nodes ✍️ to be considered successful.
• We must query R nodes 📖 for each query
  • Because at least R nodes 📖 will be at least up to date

Reads and writes that obey this R 📖 and W ✍️ values are called Quorum reads and writes.

• You can think R 📖 and W ✍️ as the minimum number of votes for the read to be valid.

In a Dynamo style databases:

• The parameters N 📚, W ✍️ and R 📖 are typically configurable
• Note, there maybe more than N 📚 nodes in a cluster
  • But any given value will be stored only on N 📚 nodes
  • This allows for data sets to be partitioned
    • Supporting data sets that are larger that can fit on 1 node

The Quorum Condition (W+R) > N

The (W+R) > N allows us to tolerate theses nodes with these types of stipulations:

• If W < N we can still process writes if a node is unavailable
• If R < N we can still process we can still process reads if a node is unavailable

For example:

• 📚 N = 3
• ✍️ W = 2
• 📖 R = 2
• We can tolerate one unavailable node

Similarly:

• 📚 = 5
• ✍️ W = 3
• 📖 R = 3
• We can tolerate 2 unavailable nodes

Normally reads and writes are always to all N 📚 replicas in parallel.

👉 Tip: The parameters N and R determine how many node we wait for…

• That is how many of the N nodes needed to report success before we consider the read and write to be successful.

👉 Tip: If there are fewer W or R nodes are available writes will return errors

• Nodes can be unavailable for many reasons
  • Node down
  • Crashing
  • Powering down
  • Error in an operation
    • Inability to write as the disc is full
  • Due to a network interruption between the client and the node
  • Etc..
• We only care if whether the node returns a successful response
  • And we do not need to distinguish between different kinds of faults

📚 Further Reading & Related Topics

If you’re exploring quorum-based reading and writing in distributed systems, these related articles will provide deeper insights:

• Distributed Data-Intensive Systems: Limitations of Quorum Consistency – Understand the trade-offs and challenges of quorum consistency in distributed databases.

• Resolving Write Conflicts in Distributed Data-Intensive Systems – Learn how distributed systems handle write conflicts, an important aspect of quorum-based replication.