CAP is important when designing cloud applications

Whether you’re moving an existing application to the cloud or starting afresh on the cloud with a brand new application, CAP is an important topic to consider when (re)designing the architecture of your app. CAP stands for Consistency, Availability and Partitioning, three characteristics that are key when designing a distributed application. These three characterictics have an important bearing on the capability of your application to scale up or down with no negative impact which is a basic requirement for cloud based applications.

So what is CAP ?

CAP is part of the Service Oriented Architecture (SOA) design principles and was first formulated by Eric Brewer in 2000 . Brewer stated that in designing a distributed application or service it is only possible to achieve two out of the three capabilities in CAP, where

• Consistency ensures that a distributed application or service has access to a consistent set of data from any node. This means ensuring that all data transactions are processed and committed fully and that the ACID related properties of a database are fully enforced
• Availability ensures that the service/application can respond to all data requests even if some of the nodes are down – so high availability and redundancy strategies are important.



• Partition tolerance ensures that the application can continue to operate even if some nodes in the distributed application / service cannot pass messages (i.e. If there is a partial network outage, your application can continue to be operational for it’s users). The risk to partition tolerance increases as data and logic moves from being centralised and are spread over different nodes

CAP in real life

To help understand these three capabilities better, lets look at some regular examples when they are combined;

• A typical centralised relational database system would be considered Consistent and Available. However when it cannot process all its transactions due to lost connections etc, it is not operating correctly and therefore not Partition tolerant.
• An online store that sells hampers would be consider Available and Partition tolerant, when a person in France buys a hamper from one server, while another Uk based customer buys a hamper from a different server, then the inventory levels in each database are not consistent. The priority here is to ensure a fully available and performant service with an objective to achieve consistency within a stated timeframe, but this is consistency with a small c.

In theory, a system can be Consistent and Parition tolerant, using the example of the online hamper store, where irrespective of where hampers are purchased, a consistent real-time view is maintained on inventory levels. The ‘but’ here is that the Consistency is maintained at the possible expense of Availability, in that if any of the regional servers were to go down, the entire store could stop operating. Availability is such a critical aspect for websites and online stores that this scenario is not practical.

CAP and Scalability

As I mentioned at the start, CAP is an important design feature in an application’s architecture. Especially when reviewing different user scenarios to design an architecture, where the application is required to scale to cope with increasing or decreasing demand. When transaction levels are low, then minor time delays can be deemed ok in order to enable data in the database to remain consistent.

However, as transaction volumes increase, if the appropriate architecture design characteristics have not been included then the user experience will deteriorate with delays and/or data inconsistencies will increase – all of which can contribute to a fall-off in business.

To illustrate this trade-off, lets look at some real-life commercial examples as discussed by Julian Browne in one of his blogs;

• Amazon claim that just an extra one tenth of a second on their response times will cost them 1% in sales
• Google said they noticed that just a half a second increase in latency caused traffic to drop by a fifth

So as not to give the wrong impression and to echo Julian’s point – discussions on the need to build in scalability in relation to different user scenarios should be driven by business requirements. Once these requirements are decided, then the appropriate architecture design considerations can then be discussed and decided upon with due consideration to the consistency, availability and partitioning requirements.

To sum up, CAP is an important part of any systems architecture – be it on the cloud, hosted or on-premises and the overall objective is to find and design the appropriate balance between the three requirements for your application.