The CAP Theorem frequently comes up in conversations around distributed systems and system design. If you’re looking at resources on system design, it will inevitably come up. However, chances are you’re not the target audience for the CAP Theorem and you’re probably better off ignoring it altogether.
CAP was presented as a keynote by Eric Brewer at a distributed computing conference in 2000. The target audience is designers of distributed systems and Eric’s 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. Relational databases had been around for over two decades at that point and most designers were comfortable with the consistency guarantees of a relational system, and Eric wanted to make the point that in order to support high availability, some level of consistency needed to be sacrificed.
Most developers being exposed to CAP nowadays are using distributed systems – not designing them. CAP was introduced to discuss trade-offs in the systems design space for the designers. So if you’re reading about CAP and wondering, “how in the world does this apply to my work?”, you’re not alone! In fact, I think it causes more confusion for developers who are already inundated by terms like consistency and availability. We’re probably better off stop talking about it.
If you’re a developer, you’re always thinking about your application data usage patterns and how your storage system supports those usage patterns at a level that is far more specific than what CAP offers you. As a distributed systems user, CAP can ultimately be reduced to “there’s a trade-off between availability and consistency”. But that’s not enough to tell you what storage system to use or how to use it.
You still need to ask questions like:
- 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?
- Can I read my own writes?
- How do I scale reads and writes? What’s the process of adding additional nodes to the system?
- How are concurrency conflicts handled? What are the cases in which it’s optimistic? Pessimistic?
- etc
CAP was not meant for you. The high level principle of consistency and availability trade-offs are arguably of some use but they don’t need to be introduced within the pretension of a “theorem”. And at the end of the day, it doesn’t really help you make effective decisions about storage systems whether it’s choosing them or tuning them. There is one plus side though – if you can explain what it is to your peers, you might look pretty smart 🙂