In 2000, Eric Brewer articulated his conjecture that of the 3 desirable properties in a distributed system, one has to choose two of them. There is no system that can be designed that gives all the 3 at any point in time and with a formal proof in 2002, this got established as the CAP theorem. The 3 desirable properties are Consistency (C), Availability (A) and Partition Tolerance (P). The 3 possible systems that can be designed are commonly referred as CA (a system that is not Partition Tolerant), AP (system that might forego consistency to stay available) and CP systems (system that might forego availability to maintain consistency). While the theorem is simple and intuitive, it can also get confusing especially when this gets associated alongside a platform or a Database system. This blog is my attempt to get a handle on the CAP intuition.
As noted by Eric himself, one can get possibly get confused when he/she relates the ‘C’ of CAP to the ‘C’ of ACID (the key properties that define most Relational Databases). While both the C’s refer to consistency, the C in CAP is a strict subset of the C in ACID. The CAP ‘C’ only refers to the single copy consistency of a data element where as the ACID ‘C’ includes much more (like a guarantee for unique keys etc.). The other source of confusion is from the way ‘Availability’ in CAP can be construed. Per the CAP intuition, a CP system is not to be construed as a system that is unavailable. It is actually a system that forfeits availability when in doubt i.e. a portion of a system is technically up and receives the request but chooses not to respond because a complementing portion of the system is unreachable.
In the subsequent paragraphs, I’ll disassociate the CAP intuition from the platform and will intuit it from a design perspective. Let us try applying CAP in the context of an online retailer. Every online retailer will most likely have 2 key functionalities – (1) To add an item to a cart/shopping bag and (2) Check the availability of the item in the inventory. Let us consider different ways of designing this system.
Imagine a retailer who is obsessed with customer satisfaction and does not want to disappoint their customers at any point. This retailer considers it a breach of contract to allow its customer to add an item to the cart that is not verified for its inventory availability. The retailer thus chooses to tightly couple the inventory check functionality to its ‘add to cart’ functionality. Such a monolithic implementation would mean the customer would not be able to add an item to his/her online cart that could not be verified for its availability. Such an implementation is a CA system.
Now consider another retailer who is proud of its strong supply chain. This retailer also does an inventory check before the ‘add to cart’ act but prefers to allow the customer add the item and proceed to an online checkout when the availability of the item could not be verified at that moment. This retailer is confident that it will be able to find the right supplier and meet the SLA for the items it promotes in its store. This retailer too implements the inventory check as part of the ‘add to cart’ feature but the implementation is not monolithic as the previous one. The ‘add to cart’ will be available for the customer even when the ‘inventory check’ is down for a brief duration. Most important, the entire implementation is kept transparent to the end customer. The customer adds such an item and even completes the order. Such an implementation is an AP system.
Now consider the third retailer who opts to take a middle path in the implementation. This retailer also chooses to check for the inventory availability at the time of ‘add to cart’. In case the ‘inventory check’ service is down, instead of deciding to continue (like the second retailer), this retailer opts to communicate the status to the customer and allows him/her to decide on the next step. Unlike the previous implementation, before taking an order, the customer is explicitly communicated about the pending ‘inventory check’ and a possible delay of shipment. Such an implementation is a CP system.