CAP Theorem Notes


What This Section Covers:

This section covers CAP theorem, what it is, and how to use it to make decisons.

CAP Theorem


What is CAP Theorem

The CAP in CAP Theorem stands for Consistency, Availability, and Partition Tolerence. The idea is that between these three properties we are only able to have two at a time.


Consistency

All nodes/users have access to the same data at the same time. This may be an important feature of say a banking or stock app, where you want the information to be as accurate as possible and avoid the situation where two users get different datapoints and metrics. Imagine that User A pulls out money from an account while User B is trying to pay for an item. User B would need to know how much money is left in the account before he buys the item and vice versa. If he tries to pay and the application gives an old value for the money, he could over spend.


Availability

This means that the server will always send back a response. It will respond to every request even if there is a failure.


Partition Tolerence

The system works dispite failures between nodes.


How To Apply CAP Theory To An Interview


Consistency or Availability?


In an interview you should first outline the functional requirements of the system. This means listing out what it should do for users and describe what the application should do.


The second thing is to talk about the non-functional requirements. This is the underlying system design that has an impact on performance characteristics of the application. This is where you would use CAP Theorem.


In a system, we always want partition tolerance because we don't want to have parts of the application fail if we want to expand to multiple nodes. The only major decison left is between availability and consistency.


Imagine that we have a server in the United States and one in Europe. We replicate data from one server to the other to keep information the same between the two systems. Imagine now that the servers get disconnected from eachother. Now, the servers may have stale data. If a user requests some data from the server during this state, do we give them stale data or an error?


Consistency

Consistency is good for applications where having stale data would be catestrophic. Think banking, booking, ticketing, and inventory systems. In these systems having accurate data is important to make decisions, which is where having consistency would be the most important. Ask: do the users need to see the most up to date information in my system? Ask: if users are given stale information, would it be catestrophic? If the answers to those are yes, than choose consistency.


Availability

Availability is good for anything where consistency is not needed. Availability is usually the default that people lean towards. Availability is good for social media sites and business sites where you just want to be available to your users.

How does the effect my design decisions?


How Does Consistency Effect My Design Decisions?


  • distributed transactions - an update in one node propogates to all nodes.

  • single node

  • higher latency

  • consensus protocols

  • database options:

    postgresql, google spanner, SQL


Usually you would use a traditional relational database management system. You can use nosql, but it is not as common for this type of application.

Types of Consistency


  • Strong consistency - This is where all reads see the most recent write.

  • Casual consistency - related events will appear in order.

  • read your writes - This is where you see your data consistently.

  • eventual consistenct - updates will propogate eventually.


How Does Availability Effect My Design Decisions?


  • Eventuall consistency is good.

  • Don't need to be consistent this moment, but gradually trend toward consistency over time.

  • You can have multiple replicas

  • change data capture - CDC

  • database options:

    dynamodb, cassandra