The CAP Theorem is one of the most important ideas in distributed system design.
It helps us reason about what happens when a distributed system experiences a network partition and multiple nodes can no longer reliably communicate with each other.
CAP stands for:
The central idea is:
In a distributed system, when a network partition occurs, you cannot simultaneously guarantee both strong consistency and availability.
This chapter builds CAP from first principles instead of treating it as a memorized acronym.
Imagine a database with two replicas:
┌──────────────┐
│ Application │
└──────┬───────┘
│
┌──────┴───────┐
│ Load Balancer│
└──────┬───────┘
│
┌───────┴────────┐
│ │
┌────▼────┐ ┌────▼────┐
│ Node A │ │ Node B │
│ balance │ │ balance │
│ ₹100 │ │ ₹100 │
└─────────┘ └─────────┘Normally:
Now suppose the network between A and B breaks:
Node A X Node B
balance=100 / \ balance=100
NETWORK PARTITIONThe system now has a difficult choice.
Should Node A:
Or should it:
If it continues accepting requests, availability improves, but replicas may disagree.
If it stops accepting requests, consistency can be protected, but availability decreases.
This is the core problem CAP describes.
In CAP, consistency has a specific distributed-systems meaning.
A useful intuition is:
Every successful read should see the most recent successful write according to a single valid ordering.
For example:
Initial:
balance = 100
Write:
balance = 50
Immediately after successful write:
Read → 50A strongly consistent system should not successfully return:
Read → 100after the system has acknowledged the write of 50, assuming the read is required to observe the latest committed value.
This idea is closely related to linearizability.
CAP consistency is often simplified as:
"All nodes have the same data."
That is not precise enough.
The important issue is what clients are allowed to observe during concurrent distributed operations.
Two replicas can temporarily contain different internal states without necessarily violating every possible consistency model.
To understand CAP consistency better, learn the idea of linearizability.
Suppose:
Client A:
write X = 20
Client B:
read XIf the write completes before the read begins, a linearizable system should make the read observe:
X = 20The system behaves as though operations happened atomically in a single valid order.
Think of it as:
Real-time order
↓
Write X=20 ──────────────► Read X
returns 20This is stronger than merely saying that replicas will eventually converge.
In CAP, availability means that:
Every request to a non-failing node receives a response.
That response does not necessarily have to contain the newest possible data under every interpretation.
The important point is that the system continues responding.
For example:
Node A ─────── Network Partition ─────── Node B
│ │
│ │
Request Request
│ │
Response ResponseIf both sides continue responding, the system is maintaining availability.
If one side refuses requests because it cannot coordinate safely, availability is reduced.
A network partition occurs when nodes that should communicate cannot reliably communicate.
For example:
Cluster
A ───── B
C ───── DSuppose the network splits:
A ─── B C ─── D
X
X
XThe nodes may still be alive.
The problem is communication.
This distinction is extremely important:
A network partition is not necessarily a server crash.
The machines can be healthy while the network between them is broken.
Distributed systems depend on communication.
Suppose:
Replica A
balance = ₹100
Replica B
balance = ₹100A user sends:
Withdraw ₹80The system needs to determine whether the operation is allowed.
Normally:
A checks balance
↓
A updates balance
↓
B learns about updateDuring a partition:
A X B
│ │
│ cannot communicate │
│ │Now both sides may receive requests.
If both accept independently, conflicting states can occur.
Consider two replicas:
┌─────────┐
│ Node A │
└────┬────┘
│
X
│
┌────┴────┐
│ Node B │
└─────────┘The network between them is partitioned.
A client sends:
Write X = 10to Node A.
Another client sends:
Write X = 20to Node B.
If both nodes continue accepting writes:
Node A → X = 10
Node B → X = 20The replicas disagree.
If the system instead prevents one or both sides from accepting operations until coordination is restored, consistency can be preserved at the expense of availability.
That is the CAP trade-off.
A practical formulation is:
When a network partition occurs, a distributed data system must choose between preserving strong consistency and preserving availability.
Therefore:
During partition:
Consistency
│
│
│
└────────────── AvailabilityYou cannot guarantee both strong consistency and availability during the partition.
You may have seen:
CAP = choose any two of C, A, P.
This is a useful beginner mnemonic, but it can be misleading.
The more accurate interpretation is:
So instead of thinking:
Pick 2 out of 3think:
A partition happens
↓
Can we still serve requests?
│
┌───┴────┐
│ │
Yes No
│ │
Availability Consistency-orientedA CP system chooses:
during a partition.
It sacrifices some availability.
Conceptually:
Partition
↓
Cannot safely coordinate
↓
Reject / delay some requests
↓
Protect consistencyExample:
Client
│
▼
Node A ───── X ───── Node B
Node A cannot safely confirm
the required distributed state.
Request → reject / waitThis is useful when returning stale or conflicting data is unacceptable.
Examples of workloads that may favor this approach include:
The exact CAP classification of a real database depends on its configuration, operation type, failure mode, and consistency guarantees.
An AP system chooses:
during a partition.
It continues serving requests even when nodes cannot communicate.
Conceptually:
Partition
↓
Nodes continue operating
↓
Clients receive responses
↓
Replicas may temporarily diverge
↓
Reconciliation laterFor example:
Node A → value = 10
Node B → value = 20After communication is restored:
reconciliation
↓
common stateThis approach can be useful when:
Again, real systems often expose configurable consistency levels rather than fitting perfectly into a single permanent CAP label.
| Property | CP Approach | AP Approach |
|---|---|---|
| Partition tolerance | Yes | Yes |
| Strong consistency during partition | Prioritized | Sacrificed |
| Availability during partition | May decrease | Prioritized |
| Stale data | Minimized | May occur |
| Conflicting writes | Avoided/restricted | May require reconciliation |
| Typical use | Coordination, strict state | Highly available distributed data |
Neither category is universally correct.
The appropriate design depends on business requirements.
Suppose:
Account balance = ₹1,000Two replicas:
Replica A = ₹1,000
Replica B = ₹1,000Network partition occurs.
Two withdrawals arrive:
User 1 → withdraw ₹800 → Replica A
User 2 → withdraw ₹800 → Replica BIf both replicas independently approve:
A → balance = ₹200
B → balance = ₹200The combined system has approved:
₹1,600from an account containing:
₹1,000This illustrates why some operations cannot simply favor availability without additional coordination or business-specific conflict handling.
Consider a social media "like" counter.
Suppose:
Post likes = 10,000A network partition occurs.
One region sees:
10,010Another sees:
10,015For many systems, temporarily showing:
10,010instead of:
10,015is acceptable.
The system can continue serving users and reconcile updates later.
The business requirement is very different from preventing duplicate financial withdrawals.
Quorums provide an important mechanism for reasoning about distributed replicas.
Suppose there are:
N = 3 replicasA system may require:
Write quorum = 2
Read quorum = 2Because:
W + R > Nwe have:
2 + 2 > 3Therefore the read and write quorums overlap.
Conceptually:
Replica 1 ──┐
Replica 2 ──┼── Write quorum
Replica 3 ──┘
Replica 2 ──┐
Replica 3 ──┼── Read quorum
┘At least one replica overlaps.
However, quorum arithmetic alone does not automatically make a system fully linearizable.
The actual semantics depend on:
For:
N = 5Possible settings:
W = 3
R = 3Then:
W + R = 6 > 5This provides overlap.
But if:
W = 1
R = 1then:
W + R = 2There is no guaranteed overlap.
This can increase availability and reduce latency but may increase the chance of stale reads.
These concepts are related but not identical.
Describes a fundamental trade-off during a network partition between:
Describes a consistency model in which:
If no new updates occur and communication continues, replicas eventually converge.
Example:
t1:
A = 10
B = 10
t2:
A = 20
B = 10
t3:
A = 20
B = 20The system was temporarily inconsistent but eventually converged.
CAP and ACID answer different questions.
ACID describes transactional properties:
CAP describes distributed-system behavior under network partition.
A useful distinction:
ACID
↓
Transaction semantics
CAP
↓
Distributed failure trade-offsDo not confuse CAP's Consistency with ACID's Consistency.
They refer to different concepts.
CAP focuses on what happens during a partition.
PACELC extends this reasoning.
A simplified form is:
If there is a Partition, choose between Availability and Consistency; Else, choose between Latency and Consistency.
Therefore:
System
│
┌────────┴────────┐
│ │
Partition? No Partition
│ │
A or C L or CWhere:
This explains why even when the network is healthy, systems still make consistency-vs-latency trade-offs.
"CAP means a system can only ever have two of the three properties."
Partition tolerance is not usually a feature you simply turn off in a real distributed system.
The practical question is:
What does the system do when a partition actually happens?
"AP means the system has no consistency."
AP systems can provide meaningful consistency guarantees.
They may sacrifice strong consistency during partitions while still providing weaker models such as eventual consistency or other session guarantees.
"CP means the system is never available."
No.
CP means availability may be sacrificed during a partition in order to preserve the chosen consistency guarantee.
When there is no partition, the system can still be highly available.
"CAP is only about databases."
No.
The underlying trade-off applies to distributed systems more broadly.
It is particularly useful for reasoning about:
"A server being down is a network partition."
Not necessarily.
A server crash is different from a communication failure.
A partition means:
Nodes cannot reliably communicate.The nodes themselves may still be running.
Suppose you are designing an inventory system.
Requirement:
Never sell more units than are actually available.
You might prioritize:
Strong consistency
+
Coordination
+
Partition-aware failure handlingNow consider a product-view counter.
Requirement:
It is okay if the count is temporarily slightly stale.
You can prioritize:
Availability
+
Partition tolerance
+
Eventual convergenceThe key skill in system design is not memorizing "CP vs AP."
The key skill is translating business requirements into consistency requirements.
When designing a system, ask:
Can the system continue operating?
If yes, availability-oriented designs become possible.
If no, stronger coordination may be required.
If yes, idempotency becomes important.
Some systems should fail closed rather than return potentially incorrect state.
Consider three replicas:
A
/ \
/ \
B-----CSuppose:
A ↔ B works
B ↔ C fails
A ↔ C failsNow imagine a write request reaches A.
A may not be able to establish the required coordination with B and C.
A consistency-oriented design might:
reject requestAn availability-oriented design might:
accept request locallyThese choices have different consequences.
Consider:
Region US
┌────────┐
│Replica │
└────────┘
X
X
WAN failure
X
X
┌────────┐
│Replica │
└────────┘
Region EUDuring a cross-region network failure, you must decide:
Protect stronger consistency.
Protect availability but potentially create divergent state.
This is one reason global distributed systems require careful consistency design.
Availability-oriented systems may need conflict resolution.
Possible approaches include:
Example:
Region A:
name = "Anubhav"
Region B:
name = "Anubhav Chaudhary"A generic timestamp rule may choose one value.
But for important business data, application-specific conflict resolution may be safer.
CAP decisions do not eliminate the need for idempotency.
Suppose a client sends:
POST /paymentThe server processes it but the response is lost.
The client retries.
Without idempotency:
Payment 1
Payment 2With an idempotency key:
request_id = abc123
First request → process
Retry → return existing resultThis is especially important in distributed systems because network failures make retries normal.
A common misconception is:
"If we wait long enough, consistency is guaranteed."
Not necessarily.
In distributed systems:
Network may be slow
Network may be broken
Node may be overloaded
Response may be lostTherefore systems use:
Timeout
↓
Retry / fail / fallbackThe timeout policy itself becomes part of system behavior.
A production distributed system needs to define:
Partition detected
↓
What should happen?
↓
Reject?
Retry?
Read stale data?
Serve cached data?
Route elsewhere?
Degrade functionality?There is no universal answer.
It depends on the business operation.
A very important system-design insight:
One system does not necessarily need the same consistency level for every operation.
For example:
Payment authorization
→ strong consistency
Product recommendations
→ eventual consistency
Like count
→ eventual consistency
User profile
→ moderate/strong consistency depending on requirements
Search index
→ eventually consistentThis allows systems to optimize different workloads independently.
Avoid saying:
"Database X is always AP."
A more accurate approach is:
"Under this configuration and failure scenario, this system provides these consistency and availability characteristics."
Modern distributed databases often provide configurable consistency levels.
Therefore system-design answers should discuss:
rather than relying only on a simplistic CAP label.
You have 3 replicas:
A
B
CA network partition isolates:
A
B
CCan A continue accepting writes while preserving strong consistency with B and C?
Not if A cannot coordinate with the other replicas and still provide the required strong consistency guarantee.
It must either:
That is the core CAP trade-off.
Why can't we simply choose all three?
Because during a network partition, independently serving requests can cause replicas to disagree.
If the system continues serving requests, it may sacrifice strong consistency.
If it refuses or delays operations to preserve strong consistency, it sacrifices availability.
Is partition tolerance optional?
In a distributed system deployed across machines or networks, communication failures are realistic.
Designing a system that assumes partitions cannot happen is unsafe.
Therefore practical distributed systems generally need to tolerate network partitions in some form.
What is the difference between CP and AP?
During a network partition:
CP-oriented behavior
Protect consistency
↓
Some requests may fail or waitAP-oriented behavior
Keep serving requests
↓
Temporary divergence may occurDoes AP mean "no consistency"?
No.
AP does not mean the system has zero consistency guarantees.
It means the system prioritizes availability during a partition rather than guaranteeing strong consistency.
The system may still provide eventual consistency or other consistency guarantees.
What is PACELC?
PACELC extends CAP:
If Partition:
choose Availability or Consistency
Else:
choose Latency or ConsistencyIt explains trade-offs even when there is no active partition.
When designing a distributed data system, document:
1. Number of replicas
2. Replication topology
3. Leader/follower or leaderless model
4. Read consistency
5. Write consistency
6. Quorum requirements
7. Partition behavior
8. Retry behavior
9. Conflict resolution
10. Recovery behavior
11. Failover strategy
12. User-visible degradationThis is much more useful than simply writing:
System = CPDesign a distributed inventory system.
Requirements:
Separate the workloads:
Product catalog
→ highly available reads
Recommendations
→ eventual consistency
Inventory reservation
→ stronger consistency
Checkout
→ transactional coordinationThe architecture should not force every operation to use the same consistency strategy.
Remember CAP using this picture:
NETWORK PARTITION
│
▼
┌─────────────────────┐
│ Communication fails │
└──────────┬──────────┘
│
┌─────────┴─────────┐
│ │
Keep serving Stop/restrict
requests requests
│ │
▼ ▼
Availability Consistency
prioritized prioritizedThe important word is:
Partition
CAP becomes meaningful because distributed systems can lose communication.
In this chapter you learned:
The most important takeaway:
When a network partition occurs, a distributed system must make a deliberate trade-off between maintaining strong consistency and continuing to serve requests.
Explain CAP in your own words using two database replicas.
What happens if:
N = 5
W = 3
R = 3Calculate whether the read and write quorums must overlap.
Classify these workloads by their likely consistency requirements:
Explain your reasoning.
Explain why:
"CAP means choose any two."
is an oversimplification.
Explain the difference between:
CAP Consistency
vs
ACID ConsistencyDesign a multi-region shopping-cart system.
Requirements:
Document:
Architecture
↓
Replication
↓
Consistency model
↓
Partition behavior
↓
Conflict resolution
↓
RecoveryDo not simply label the whole system CP or AP.
Identify the consistency requirement for each operation.
Before shipping a distributed system, ask:
If an interviewer asks:
"Explain CAP theorem."
A strong answer can be:
CAP theorem describes a fundamental trade-off in distributed systems during a network partition. The three concepts are consistency, availability, and partition tolerance. In a real distributed system, network partitions can occur, so during a partition the system generally has to choose whether to preserve strong consistency or continue serving requests with availability. A CP-oriented system may reject or delay some operations to protect consistency, while an AP-oriented system continues serving requests and may allow temporary divergence. CAP should not be reduced to the phrase "choose any two"; the important question is how the system behaves under partition.
That answer demonstrates understanding rather than memorization.
In the next chapter, we will go deeper into consistency itself.
We will study:
Mark it as complete to track your mastery.