Due to the quorum requirements, probability of failure increases with larger quorum sizes, as the number of intersections (and therefore potential points of failure) increases with more complex quorum arrangements.
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.
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
"Consistency models in distributed systems: A survey on definitions, disciplines, challenges and applications" - https://ar5iv.labs.arxiv.org/html/1902.03305