CAP theorem is one of the most important concepts for a Solutions Architect because it helps you explain architecture trade-offs in distributed systems.
CAP in one sentence
When a distributed system experiences a network partition, you must choose between Consistency and Availability.
The three letters are:
C — Consistency
A — Availability
P — Partition Tolerance
1. What does C, A and P mean?
C — Consistency
Every node returns the latest/correct data.
Imagine you have two database servers:
Database
/ \
Node A Node B
You update your bank balance on Node A:
Balance = £1,000
↓
Balance = £800
With strong consistency, if you immediately read the balance from Node B, you should also see:
£800
You shouldn't get the old value of £1,000.
Think: "Is my data correct everywhere?"
A — Availability
Every request receives a response.
Even if one server is unavailable:
Database
/ \
Node A Node B
❌ ✅
↓
Request
↓
Response
The system continues responding rather than simply failing the request.
Think: "Is my system responding?"
P — Partition Tolerance
This is probably the most confusing one.
A network partition occurs when nodes cannot communicate with each other.
Node A
|
| ❌ NETWORK FAILURE
|
Node B
Or:
Network
|
┌──────┴──────┐
↓ ↓
Node A Node B
✅ ✅
\ /
\---- ❌ -----/
partition
Both servers may still be running, but they can't communicate.
Partition tolerance means the system continues operating despite this communication failure.
2. The important part of CAP
Here's where the interview question becomes interesting.
Suppose you have:
Application
|
┌────────┴────────┐
↓ ↓
Node A Node B
£100 £100
Now the network between A and B fails:
Node A ❌ Node B
£100 £100
A customer sends a request to Node A:
"Withdraw £50."
Node A now says:
£100 → £50
But Node B doesn't know about the change.
Node A Node B
£50 £100
❌ NETWORK PARTITION ❌
Now we have a problem.
If a customer asks Node B:
"What's my balance?"
Should it return £100 or should it refuse the request?
That's where CP vs AP comes in.
3. CP — Consistency + Partition Tolerance
With a CP system, when there's a network partition, the system prioritises correct/consistent data over availability.
Application
|
┌───────┴───────┐
↓ ↓
Node A Node B
£50 £100
\ /
\_____ ❌ _____/
partition
Node B might say:
"I cannot safely process this request because I can't confirm the latest data."
So:
Consistency ✅
Partition Tolerance ✅
Availability ❌
Some requests may fail or wait.
When would you want CP?
When incorrect data is worse than downtime.
Examples:
Banking transactions
Payment processing
Inventory
Airline seat booking
Order processing
Financial systems
Imagine an airline has one seat left.
Two users try to book it at exactly the same time.
You don't want:
User A → SUCCESS
User B → SUCCESS
for the same seat.
You'd rather reject one request:
User A → SUCCESS
User B → FAILED
That's a consistency-first approach.
4. AP — Availability + Partition Tolerance
With an AP system, the system continues responding even when parts of the network cannot communicate.
Application
|
┌───────┴───────┐
↓ ↓
Node A Node B
£50 £100
\ /
\_____ ❌ _____/
partition
Both nodes continue responding.
The problem is that they may temporarily have different data.
Node A → £50
Node B → £100
Eventually, they can synchronise once communication is restored.
So:
Availability ✅
Partition Tolerance ✅
Immediate Consistency ❌
When would you want AP?
When availability is more important than having perfectly up-to-date data.
Examples include:
Social media feeds
Product catalogues
Recommendations
Shopping carts in some designs
Content delivery
Some messaging systems
For example, imagine Instagram.
If your friend posts a photo, it's probably acceptable if:
User A sees the photo immediately
User B sees it 2 seconds later
You don't want Instagram to shut down globally just because two database nodes temporarily can't communicate.
5. What about CA?
You may see:
CA = Consistency + Availability
But there's an important interview nuance.
CAP assumes a distributed system can experience network partitions.
If you don't tolerate partitions:
C + A
is possible only when there is no partition.
For example, a traditional database running in a single reliable environment might provide strong consistency and availability under normal conditions.
But once you introduce distributed nodes and network failures, partition tolerance becomes important.
That's why you'll commonly hear:
Distributed systems generally choose between CP and AP.
6. A very easy real-world example
Imagine a supermarket with two branches sharing inventory.
Inventory System
┌───────────────┐
│ Central Data │
└───────┬───────┘
|
┌──────┴──────┐
↓ ↓
Store A Store B
10 TVs 10 TVs
Now the network connection breaks.
Store A ❌ Store B
10 TVs 10 TVs
A customer buys the last TV from Store A.
Store A:
10 → 0
But Store B still thinks:
10 TVs available
CP approach
Store B says:
"I can't confirm inventory, so I won't sell the item."
This protects consistency.
AP approach
Store B says:
"I have inventory according to my local data, so I'll accept the order."
This protects availability.
But you now have to deal with the possibility of inconsistent inventory.
7. CAP vs database choice
This is an important Solutions Architect interview point.
Don't say:
"MongoDB is AP, therefore I'll always use MongoDB."
That's too simplistic.
The real question is:
What does the business require during a network partition?
You should first understand:
How much downtime can the business tolerate?
Can users tolerate stale data?
Can incorrect data cause financial loss?
How quickly must the system respond?
What consistency model is required?
What are the recovery requirements?
Then choose the architecture.
8. How to answer CAP in an interview ⭐
If the interviewer asks:
"Explain CAP theorem."
A strong answer would be:
"CAP theorem states that in a distributed system, when a network partition occurs, we have to make a trade-off between consistency and availability. Consistency means that clients see the latest valid data, availability means that the system continues responding to requests, and partition tolerance means the system continues operating despite communication failures between nodes. Since network partitions are unavoidable in distributed systems, in practice we generally choose between CP and AP depending on the business requirements. For example, a banking transaction would typically prioritise consistency, whereas a social media feed may prioritise availability and tolerate some eventual consistency."
That's a very good Solutions Architect answer.
9. CAP and "eventual consistency"
You'll often hear these two together.
Strong consistency:
Write → Synchronise → Read
↓
Latest data
Eventual consistency:
Write → Node A updated
↓
Node B temporarily old
↓
Synchronisation
↓
Both eventually
agree
For example:
12:00:00 User updates profile
↓
Node A = "John Smith"
Node B = "John"
12:00:01 Replication occurs
↓
Node B = "John Smith"
The system was temporarily inconsistent, but eventually became consistent.
🧠 The easiest way to remember CAP
Think of the three questions:
C — Is the data correct everywhere?
A — Will the system always respond?
P — Can the system survive network communication failures?
And remember the key interview statement:
When a partition happens, you generally choose between CP and AP.
And the architectural thinking is:
NETWORK PARTITION
│
┌─────────┴─────────┐
↓ ↓
CP AP
│ │
Consistency Availability
is priority is priority
│ │
"I'd rather "I'd rather
reject a request respond with
than return wrong potentially
data." stale data."
That's the real value of CAP theorem for a Solutions Architect: it gives you a framework for explaining and justifying architectural trade-offs.