REVIEW 3 cited by
A Critique of the CAP Theorem
Not yet reviewed by Pith; the record is open.
This paper has not been read by Pith yet. Machine review is queued; the pith claim, tier, and objections will appear here once it completes.
SPECIMEN: schema-true, not a live event
T0 review · schema-true
One-sentence machine reading of the paper's core claim.
pith:XXXXXXXX · record.json · timestamp
read the original abstract
The CAP Theorem is a frequently cited impossibility result in distributed systems, especially among NoSQL distributed databases. In this paper we survey some of the confusion about the meaning of CAP, including inconsistencies and ambiguities in its definitions, and we highlight some problems in its formalization. CAP is often interpreted as proof that eventually consistent databases have better availability properties than strongly consistent databases; although there is some truth in this, we show that more careful reasoning is required. These problems cast doubt on the utility of CAP as a tool for reasoning about trade-offs in practical systems. As alternative to CAP, we propose a "delay-sensitivity" framework, which analyzes the sensitivity of operation latency to network delay, and which may help practitioners reason about the trade-offs between consistency guarantees and tolerance of network faults.
Forward citations
Cited by 3 Pith papers
-
A Framework for Consistency Models in Distributed Systems
A new axiomatic framework unifies classic consistency models and proves CLAM, a trilemma showing wait-free distributed systems must sacrifice one of closed past, local visibility, or arbitration.
-
Light Cone Consistency: Closure, Ordering, and the Single-Observer Boundary
Light Cone Consistency unifies 50+ consistency models as configurations of causal closure, fork resolution, and timeliness on causal logs and shows that CAP, FLP, and AFC form an entangled impossibility triangle that ...
-
Did we miss P In CAP? Partial Progress Conjecture under Asynchrony
CASSANDRA lets partitioned replicas speculatively order requests during a partition and claims that at least one partition's transactions will persist after recovery.
Discussion (0). Continue with ORCID to comment.