Eric Brewer
ABSTRACT
At PODC 2000, the CAP theorem received its first broad audience. Surprisingly for an impossibility result, one important effect has been to free designers to explore a wider range of distributed systems. Designers of wide-area systems, in which network partitions are considered inevitable, know they cannot have both availability and consistency, and thus can now justify weaker consistency. The rise of the "NoSQL" movement ("Not Only SQL") is an expression of this freedom.
The choices of how and when to weaken consistency are often the defining characteristics of these systems, with new variations appearing every year. We review a variety of interesting places in the "CAP Space" as a way to illuminate these issues and their consequences. For example, automatic teller machines (ATMs), which predate the CAP theorem, surprisingly choose availability with weak consistency but with bounded risk.
Finally, I explore a few of the options to try to "work around" the impossible. The most basic is the use of commutative operations, which make it easy to restore consistency after a partition heals. However, even many commutative operations have non-commutative exceptions in practice, which means that the exceptions may be incorrect or late. Adding the concept of "delayed exceptions" allows more operations to be considered commutative and simplifies eventual consistency during a partition. Furthermore, we can think of delayed exception handling as "compensation" - we execute a compensating transaction that restores consistency.
Delayed exception handling with compensation appears to be what most real wide-area systems do - inconsistency due to limited communication is treated as an exception and some exceptional action, such as monetary compensation or even legal action, is used to fix it. This approach to wide-area systems puts the emphasis on audit trails and recovery rather than prevention, and implies that we should expand and formalize the role of compensation in the design of complex systems
Index Terms
- A certain freedom: thoughts on the CAP theorem
Recommendations
The CAP theorem versus databases with relaxed ACID properties
ICUIMC '14: Proceedings of the 8th International Conference on Ubiquitous Information Management and CommunicationThe CAP theorem combines the three desirable properties C (data consistency), A (data availability), and P (partition-tolerance: tolerance of inconsistencies between data stored in a distributed database where partitions are allowed). The CAP theorem ...
Pushing the CAP: Strategies for Consistency and Availability
The CAP theorem asserts that any networked shared-data system can have only two of three desirable properties. However, by explicitly handling partitions, designers can optimize consistency and availability, thereby achieving some trade-off of all ...
Flexible Integration of Eventually Consistent Distributed Storage with Strongly Consistent Databases
NCCA '12: Proceedings of the 2012 Second Symposium on Network Cloud Computing and ApplicationsIn order to design distributed business applications or services, the common practice consists in setting up a multi-tier architecture on top of a relational database. Due to the recent evolution of the needs in terms of scalability and availability in ...
Comments