# Understanding the CAP Theorem in 2 Minutes

Choosing your database is always a long road paved with pros, cons, and trade-offs… but when you have to go with a distributed database, the challenge is even bigger!

If the concept of a distributed database is unfamiliar to you, check out our article on database sharding

To put it simply, distributed (or sharded) data is spread across several nodes (servers), which can themselves be spread across several data centers, in several countries!

The three strategic properties

It's important to know that having your data spread across multiple machines adds a few extra constraints.

Ideally, no matter how many servers there are, we'd like every request to return a correct result.

In this sentence, we find three important concepts: Consistency, data availability, and partition tolerance.

Consistency

Consistent data is data that has only one visible, valid state.

This holds true regardless of how many machines have a copy of it, or how often that data is updated.

For example, when you perform a cash withdrawal at an ATM, the balance displayed must be accurate and up to date. Even if several ATMs are in service, they must all show the same balance after a successful transaction in order to maintain the consistency of the financial data.

Availability

Data must be available, accessible, for reading.

This means that every request will necessarily get a response, regardless of the state of the system.

For example, social media sites like Twitter (X) must be available at all times so that users can post tweets, even in the event of a partial system failure. Even though some tweets may take some time to propagate to all servers, users must always be able to access the service and interact with their own tweets and those of others.

Partition tolerance

Sometimes people also simply call this "partitioning," but this term is too often confused with "sharding," which is the core principle of distributed data itself.

A partition occurs when one of the machines holding part of your data stops responding. This can be caused by:

• A hardware issue
• A software issue
• A network outage

Partition tolerance means that the system must keep responding, even if part of your data is missing (or inaccessible), even temporarily!

For example, if a data center is disconnected from the rest of the network due to a connectivity outage, the other data centers must be able to keep functioning and serving user requests without interruption.

The CAP theorem (or Brewer's theorem)

The CAP theorem states that a distributed database can only simultaneously guarantee 2 out of 3 properties at most. Namely:

• Consistency + Availability (CA)
• Consistency + Partition tolerance (CP)
• Availability + Partition tolerance (AP)

This theorem is often represented as a triangle, like this one:

And you can only choose one side at a time!

The CA paradigm

By choosing this paradigm, your queries will always receive a complete and consistent response, unless a node becomes unavailable (partition).

In the event of a partition, your system will stop responding.

The CP paradigm

By tolerating faults and ensuring data consistency, you give up availability.

The data will always be reliable, but if the reliable data is inaccessible, then the query will return no result.

The AP paradigm

By tolerating faults and ensuring availability, you give up consistency.

The query will always return a result, but the data may be stale or out of sync.

Databases

This theorem is an essential guide for making decisions when you need to distribute your data, depending on the constraints of your project.

Here is a list of major databases and their implementation of the CAP theorem:

Relational

MySQL (CA), SQLServer (CA), PostgresQL (CA), Oracle (CA), DB2 (CA)

Key-Value

Redis (AP), Memcached (AP or CP), SimpleDB (AP or CP), SimpleDB (AP or CP), CosmosDB (CP or AP)

Column

ElasticSearch (AP), Spark (AP), HBase (CP), BigTable (CP)

Document

MongoDB (CP or AP), DynamoDB (AP or CP), Couchbase (AP or CP), Cassandra (AP or CP)

Graph

Neo4J (AP), OrientDB (AP), FlockDB (AP)

Of course, choosing a database also depends on other factors such as available skills, time, resources, the community…