Most of us have heard the popular proverb \u201cyou can\u2019t have your cake and eat it too\u201d. The literal meaning of this is that if you eat your cake, then it is gone, so you no longer have it. Metaphorically it teaches us that we cannot have two incompatible things.<\/p>\n
CAP theorem (aka Brewer\u2019s theorem from Eric Brewer) makes a similar assertion for distributed computer systems. CAP theorem states that you can have at most two of the following three properties; Consistency<\/em>, Availability<\/em>, and Partition Tolerance<\/em>, because any two are mutually exclusive to the third. A brief outline of the properties follows:<\/p>\n For a simple example, let\u2019s assume we have a distributed system with 2 partitioned nodes, node-A and node-B. Having two nodes improves availability<\/em> because each is independently capable of providing services. If node-A\u2019s state is updated while the nodes are partitioned then node-B becomes inconsistent. We can ensure that the system maintains consistency<\/em> by making node-B appear unavailable, but this requires us to give up availability<\/em>. In order to have both consistency<\/em> and availability<\/em> we must allow both nodes to communicate, which gives up partition tolerance<\/em>. This example illustrates that it isn\u2019t possible to have all properties maximized; compromises need to be made. Traditionally, large distributed systems required partition tolerance<\/em> so designers had to choose between consistency<\/em> and availability<\/em> for the second property.<\/p>\n CAP theorem first appeared in 1998 and it still holds today, but savvy designers are able to play fast-and-loose with the \u201cchoose 2 out of 3\u201d rule. One thing in the designer\u2019s favor is that partitions are relatively rare in distributed systems. Another boon to the designer are modern techniques that grant flexibility when handling partitions and recovering from them after they happen. These allow designers to focus on maximizing combinations of consistency<\/em> and availability<\/em> for the specific need of the application until a partition actually occurs. When it does occur, the system may need to fall back to favoring either availability<\/em> or consistency<\/em> until the partition ends.<\/span><\/p>\n There are still significant challenges in making this all work, such as detecting when a partition has occurred and implementing a recovery strategy when it does. For example, if availability<\/em> is the chief concern during a partition event, the state of multiple nodes can progress independently and will need to be merged once the partition ends. The merge itself may present conflicts that will need to be dealt with by the system in order to return to a consistent state.<\/p>\n That\u2019s a very brief summary of CAP theorem. It tells us that when designing distributed computer systems we need to make compromises in order to achieve certain desirable characteristics. As architecture techniques and tools evolve, designers are able to maximize combinations of the properties depending on the state of the system. Even with these advancements, however, designers still cannot maximize all properties at all times; they cannot have their cake and eat it too.<\/p>\n","protected":false},"excerpt":{"rendered":" Most of us have heard the popular proverb \u201cyou can\u2019t have your cake and eat it too\u201d. The literal meaning of this is that if you eat your cake, then it is gone, so you no longer have it. Metaphorically it teaches us that we cannot have two incompatible things. CAP theorem (aka Brewer\u2019s theorem from Eric Brewer) makes a similar assertion for distributed computer systems. CAP theorem states that you can have at most two of the following three…<\/p>\n\n
\nWhy are we limited to two?<\/strong><\/p>\n