eric brewer presented CAP at a distributed computing conference in 2000 to designers of distributed systems, most of whom were familiar with relational databases and their consistency guarantees. His intention was to start the conversation about trade-offs in the system design space that need to be made between consistency and availability for early cloud-based storage systems that needed to be highly available. His main argument was that systems that for cloud storage systems to be highly available, some level of consistency needed to be sacrificed.
most developers like myself are using distributed systems – not designing them. more importantly, i find that i’m often required to think about app data usage patterns and how their storage system supports those usage patterns at levels far more granular than what CAP offers. as a distributed systems user, CAP can basically be reduced to “there’s a trade-off between availability and consistency”. that’s a concept that i find much easier to digest on its own
more useful questions / concepts than CAP to grapple with are…
- is replication synchronous or asynchronous? Is this adjustable?
- In the event of node or network failures, what is the data recovery process like? what writes get rolled back?
- is there support for transactions? what level of isolation is supported (are dirty reads possible?)
- can I read my own writes?
- how do I scale reads and writes as my system grows? what does the process of adding additional nodes to the system look like?
- how are concurrency conflicts handled / when there is contention over shared data?