3 ms·

> Due to the quorum requirements, probability of failure increases with larger quorum sizes Well, that's not true due to two key design points: - Size of the

> Due to the quorum requirements, probability of failure increases with larger quorum sizes Well, that's not true due to two key design points: - Size of the read or write quorum can be chosen on a per transaction basis depending on what level of availability and consistency you want. The design goal is to lower the likelyhood of the minimum number of quorum members you need for your transaction will not be available. - Given the transaction processing nodes are ephemeral and independent from storage nodes, if a transaction processing node which is designated as a member of a quorum dies, it can be quickly and instantly replaced with a new one and all in-flight operations will be retried by the smart clients.

belter 3y ago
While all those design strategies are indeed valid, and adaptable dynamic quorum sizes, have the potential to manage certain trade-offs, the practical implementation of such systems presents such a challenges, due to the inherent complexities of distributed systems that...Tackling these complexities with those strategies should be approached with a degree of humility. Overheads and latency issues in node replacement, particularly under conditions of unexpected high load or network difficulties, compound these challenges. These issues often manifest in correlated failures, which are more common than isolated node failures. In this landscape we are still in compromise and trade-offs territory. I would refer to these two papers as insightful demonstrations of these challenges: "Consistency vs. Availability in Distributed Real-Time Systems" - https://ar5iv.labs.arxiv.org/html/2301.08906v1 https://ar5iv.labs.arxiv.org/html/2301.08906v1 "Consistency models in distributed systems: A survey on definitions, disciplines, challenges and applications" - https://ar5iv.labs.arxiv.org/html/1902.03305 https://ar5iv.labs.arxiv.org/html/1902.03305

belter 3y ago

While all those design strategies are indeed valid, and adaptable dynamic quorum sizes, have the potential to manage certain trade-offs, the practical implementation of such systems presents such a challenges, due to the inherent complexities of distributed systems that...Tackling these complexities with those strategies should be approached with a degree of humility. Overheads and latency issues in node replacement, particularly under conditions of unexpected high load or network difficulties, compound these challenges. These issues often manifest in correlated failures, which are more common than isolated node failures. In this landscape we are still in compromise and trade-offs territory. I would refer to these two papers as insightful demonstrations of these challenges: "Consistency vs. Availability in Distributed Real-Time Systems" - https://ar5iv.labs.arxiv.org/html/2301.08906v1 https://ar5iv.labs.arxiv.org/html/2301.08906v1 "Consistency models in distributed systems: A survey on definitions, disciplines, challenges and applications" - https://ar5iv.labs.arxiv.org/html/1902.03305 https://ar5iv.labs.arxiv.org/html/1902.03305