CAP Theorem Explained: Consistency, Availability & Partition Tolerance
CAP Theorem Explained: Consistency, Availability & Partition Tolerance
In a distributed system, data lives on multiple machines connected by a network. When everything works perfectly, those machines can stay in sync and respond to every request. But real networks are unreliable. Cables fail, routers reboot, and data centres lose connectivity. When that happens, the system must make a hard choice.
The CAP theorem states that a distributed data store can guarantee at most two of the following three properties at the same time:
- Consistency — every read receives the most recent write
- Availability — every request receives a response, even if some nodes fail
- Partition tolerance — the system continues to operate despite network failures
In this guide, you will learn what the CAP theorem means, why it matters, and how real databases choose between CA, CP, and AP architectures. If you are studying databases or distributed systems, you may also want to read our overview of types of database systems.
What is the CAP Theorem?
The CAP theorem, also known as Brewer's theorem, was introduced by computer scientist Eric Brewer around 2000. It describes the fundamental trade-offs faced by distributed systems when handling network failures.
A distributed system stores data across multiple nodes. Those nodes communicate over a network, and the network can sometimes split into isolated segments. This event is called a network partition. When a partition occurs, some nodes can no longer talk to each other, but both sides may still receive requests from clients.
The CAP theorem tells us that when a partition happens, the system must choose between:
- Remaining consistent by refusing to serve stale data, or
- Remaining available by responding to requests even if the data may not be up to date
It is impossible to guarantee both consistency and availability during a partition. Therefore, distributed systems are usually designed as CP or AP systems. Single-node systems can be CA because they do not face network partitions.
The theorem is foundational for system design, database selection, and building scalable backend services. For a structured path into this topic, the Scaler System Design Course covers distributed systems, databases, and trade-offs in depth.
The Three Components of CAP
To understand the CAP theorem, you must first understand its three components clearly.
Transform Your Career
Choose from our industry-leading programs designed for career success
Modern Software and AI Engineering Program
Master full-stack development with AI integration
+1000 moreModern Data Science and ML with specialisation in AI
Advanced data science techniques with AI specialization
+1000 moreAdvanced AIML with Specialisation in Agentic AI
Deep dive into AIML with focus on Agentic systems
+1000 moreDevOps, Cloud & AI Platform Engineering
Build and manage AI-powered cloud infrastructure
+1000 moreAI Engineering Advanced Certification by IIT-Roorkee
Premier AI engineering certification from IIT-Roorkee
Consistency
In CAP, consistency means that every read operation returns the most recent write or an error. All nodes in the system see the same data at the same time. If one node accepts a write, every other node must reflect that write before any read can return an old value.
This is sometimes called strong consistency or linearizability. It is the same idea behind ACID guarantees in traditional relational databases.
Example: If you update your profile picture on a strongly consistent system, every user who views your profile immediately sees the new picture.
Availability
Availability means that every request receives a non-error response, without guaranteeing that the response contains the most recent write. The system remains operational even if some nodes fail or are unreachable.
High availability is important for systems that cannot afford downtime, such as e-commerce websites, payment gateways, and global messaging platforms.
Example: A search engine might return slightly stale results instead of failing when a data centre becomes unreachable.
Partition Tolerance
Partition tolerance means the system continues to operate even when the network is broken into disconnected segments. A partition-tolerant system does not stop working just because some nodes cannot communicate.
In real distributed systems, network partitions are unavoidable. Therefore, partition tolerance is effectively non-negotiable for any serious distributed database.
To understand why networks fail, read our guide on computer networks, which covers the protocols and failure modes behind distributed systems.
Why You Can Only Pick Two
The CAP theorem is often summarised as "pick two out of three." But in practice, the real choice is between consistency and availability, because partition tolerance is almost always required.
Imagine a distributed database with two nodes, Node A and Node B. They are connected over a network, and a client writes data to Node A. Before Node A can respond successfully, it must replicate the write to Node B.
Now suppose a network partition occurs and Node A cannot reach Node B. If the system keeps accepting writes on Node A, then Node B will be out of date, and reads from Node B will return stale data. That violates consistency.
On the other hand, if the system refuses to accept writes until the partition heals, it remains consistent but becomes unavailable for writes. That violates availability.
Because both cannot be guaranteed during a partition, the system must choose one. This is the heart of the CAP theorem.
Venn Diagram Description
Picture three overlapping circles labelled Consistency, Availability, and Partition Tolerance. In the centre, where all three overlap, there is a warning sign: "Impossible during a partition." Instead, distributed systems usually settle along one of the two edges:
- CP systems cover the consistency and partition tolerance circles.
- AP systems cover the availability and partition tolerance circles.
- CA systems cover only consistency and availability, meaning they assume a single node or a network that never partitions.
CA, CP and AP Systems (with Database Examples)
Real-world databases and distributed systems are classified based on which two CAP properties they prioritise. Here is how the trade-offs map to well-known systems.
CA Systems (Consistency + Availability, no Partition Tolerance)
CA systems assume the network is reliable and does not partition. They are typically traditional relational databases running on a single node or within a tightly controlled local cluster.
Examples:
- A single-node PostgreSQL or MySQL instance
- A monolithic SQL server inside a single data centre
CA systems are not truly distributed. If the network partitions, they cannot maintain both consistency and availability.
Scaler Placement Report and Statistics
Scaler learners achieved 2.5x salary growth with average post-Scaler CTC reaching ₹23L.
Google
Amazon
Microsoft
Flipkart
Adobe1200+ moreCP Systems (Consistency + Partition Tolerance)
CP systems choose consistency over availability during a partition. If a node cannot reach the majority of the cluster, it may refuse to serve requests to avoid returning stale data.
Examples:
- MongoDB — when configured with strong consistency and majority writes
- ZooKeeper — strongly consistent coordination service
- etcd — distributed key-value store used by Kubernetes
- HBase — column-family store built on HDFS and ZooKeeper
CP systems are ideal for applications where data correctness is more important than always being online, such as financial ledgers, inventory systems, and configuration stores.
AP Systems (Availability + Partition Tolerance)
AP systems choose availability over strong consistency during a partition. They continue to respond to requests even when nodes are disconnected, and they reconcile differences later. This approach is often called eventual consistency.
Examples:
- Cassandra — distributed wide-column store
- Amazon DynamoDB — configurable, but often used with eventual consistency
- Couchbase — document-oriented NoSQL database
- Riak — distributed key-value store
AP systems are ideal for applications that must remain online at all times, such as social media feeds, recommendation engines, and global content delivery systems.
CA, CP, AP Comparison Table
| Category | Properties | Behaviour During Partition | Example Databases | Best For |
|---|---|---|---|---|
| CA | Consistency + Availability | Assumes no partition | Single-node PostgreSQL, MySQL | Small, single-node systems |
| CP | Consistency + Partition Tolerance | Blocks or errors to avoid stale data | MongoDB, ZooKeeper, etcd, HBase | Financial systems, strong consistency needs |
| AP | Availability + Partition Tolerance | Returns possibly stale data | Cassandra, DynamoDB, Couchbase, Riak | High availability, global scale |
For more on NoSQL databases that often fall into the CP or AP categories, see our article on NoSQL databases.
CAP Theorem in DBMS and NoSQL
The CAP theorem is especially important when choosing between SQL and NoSQL databases.
Traditional relational databases are designed around ACID properties:
- Atomicity — all operations in a transaction succeed or fail together
- Consistency — the database remains in a valid state after every transaction
- Isolation — concurrent transactions do not interfere with each other
- Durability — committed data is safe even after a crash
ACID databases usually favour consistency. In a single-node setup, they can also be considered CA systems because they do not need to handle partitions across the network.
NoSQL databases often follow the BASE model, which is more aligned with AP systems:
- Basically Available — the system is available most of the time
- Soft state — state may change without input, due to eventual consistency
- Eventual consistency — data will become consistent over time, given no new updates
BASE systems are designed for high availability and horizontal scalability. They accept that some reads may be temporarily stale in exchange for better uptime and performance.
Understanding these trade-offs is essential for database design. You can strengthen your DBMS foundation with the free DBMS course from Scaler.
Turn Learning into Career Growth
Beyond CAP: The PACELC Theorem
The CAP theorem only describes what happens during a network partition. But what about trade-offs when the network is healthy? The PACELC theorem extends CAP to address this question.
PACELC states:
If there is a Partition (P), you must choose between Availability (A) and Consistency (C). Else (E), when the system is running normally, you must choose between Latency (L) and Consistency (C).
In other words, even when there is no partition, distributed systems face a trade-off between low latency and strong consistency. Strong consistency usually requires more coordination between nodes, which increases latency. High availability and low latency often require relaxing consistency.
This extension is important because most real-world systems spend far more time running normally than handling partitions. PACELC gives a fuller picture of the design choices behind distributed databases.
Daniel Abadi, who introduced PACELC, discussed the evolution of CAP in the well-known InfoQ article "CAP Twelve Years Later: How the Rules Have Changed," co-authored with Eric Brewer. You can read it here: CAP Twelve Years Later.
Real-World Example of CAP in Action
Consider an e-commerce website that tracks product inventory across two warehouses. Each warehouse has its own database node, and they replicate stock updates to each other.
Scenario: A network partition occurs
A customer buys the last unit of a popular product from Warehouse A. The update must reach Warehouse B before the next customer can see accurate inventory.
Option 1: Choose consistency (CP behaviour)
The system refuses to process any new orders until the partition heals and the stock update is confirmed on both nodes. Customers may see an error or timeout, but they will never buy an item that is out of stock. This protects data correctness but hurts availability.
Option 2: Choose availability (AP behaviour)
The system continues accepting orders on both nodes. Warehouse A shows zero stock, but Warehouse B still shows one unit because the update has not arrived. A second customer places an order for the same product from Warehouse B, causing an oversell. The system remains available but is temporarily inconsistent.
After the partition heals, the system must reconcile the two conflicting records. It might cancel one order, request more stock, or refund the customer. This is how eventual consistency works in practice.
Conclusion
The CAP theorem is one of the most important ideas in distributed systems. It states that a distributed system can guarantee at most two of consistency, availability, and partition tolerance. Because network partitions are unavoidable in real distributed systems, the practical choice is between CP systems that favour consistency and AP systems that favour availability.
Understanding CAP helps you choose the right database and architecture for your application. Strong consistency matters for financial and inventory systems, while high availability matters for social media, search, and global services. The PACELC theorem reminds us that latency and consistency trade-offs exist even when the network is healthy.
To continue learning, explore the Scaler System Design Course, the free DBMS course, or browse all Scaler courses.
FAQs
Q1. What is the CAP theorem?
The CAP theorem states that a distributed data store can guarantee at most two of three properties at the same time: consistency, availability, and partition tolerance. It was introduced by computer scientist Eric Brewer around 2000 and is a fundamental principle for designing distributed systems. When a network partition occurs, the system must choose between consistency and availability.
Q2. What do consistency, availability and partition tolerance mean?
Consistency means every read returns the most recent write. Availability means every request receives a response, even if some nodes are down. Partition tolerance means the system continues to operate despite network failures that prevent nodes from communicating. In real distributed systems, partition tolerance is considered essential because networks are never perfectly reliable.
Q3. Why can you only choose two of the three?
During a network partition, nodes are split into isolated groups that cannot synchronise. If the system continues accepting writes on both sides, the nodes will diverge and reads may return stale data, breaking consistency. If the system stops accepting writes to keep data consistent, it becomes unavailable for some requests. Therefore, all three properties cannot be guaranteed simultaneously.
Q4. What are CA, CP and AP systems?
CA systems favour consistency and availability but assume no network partitions; they are usually single-node relational databases. CP systems favour consistency and partition tolerance, blocking requests during partitions to avoid stale data. AP systems favour availability and partition tolerance, continuing to serve requests and reconciling inconsistencies later. Examples include MongoDB and ZooKeeper for CP, and Cassandra and DynamoDB for AP.
Q5. Who proposed the CAP theorem?
The CAP theorem was proposed by Eric Brewer, a computer science professor at the University of California, Berkeley. He introduced the idea around 2000 in a keynote talk about distributed web services. Later, Seth Gilbert and Nancy Lynch of MIT provided a formal proof of the theorem. Brewer also co-authored the influential follow-up article "CAP Twelve Years Later," which refined the understanding of the trade-offs.
Q6. What is the difference between CAP and PACELC?
CAP describes the trade-off between consistency and availability during a network partition. PACELC extends this by stating that if there is a partition, you choose between availability and consistency; otherwise, when the system is running normally, you choose between latency and consistency. PACELC is useful because it captures the real-world trade-offs that systems face even when no partition is occurring.
