System Design Journey — Chapter 6: CAP Theorem (Introduction)

Today’s lesson completely changed how I think about distributed systems.

Like many developers, I had always heard:

“In distributed systems, you can only choose two: Consistency, Availability, and Partition Tolerance.”

It turns out that’s one of the biggest misconceptions in System Design.

What is the CAP Theorem?

The CAP Theorem states that when a network partition occurs, a distributed system must choose between:

• Consistency ( C ) — Every user sees the latest, correct data.
• Availability (A) — Every request receives a response, even if the data might be slightly outdated.
• Partition Tolerance (P) — The system continues operating even when communication between servers is interrupted.

The important part is “when a network partition occurs.”

Modern distributed systems communicate over networks, and networks are never 100% reliable. Servers can lose connectivity due to router failures, cloud outages, firewall issues, or network congestion.

This means Partition Tolerance isn’t really optional — it’s a reality.

The Biggest Misconception

The famous statement:

“Choose any two out of three.”

isn’t entirely accurate.

A better way to think about CAP is:

When a partition happens, you must decide between Consistency and Availability.

That small wording change completely changed my understanding of the theorem.

A Simple Example

Imagine your shipping address is stored in two database replicas.

You update your address, but before the second replica receives the update, a network partition occurs.

Now another user request reaches the second database.

The system has two choices:

Option 1 — Prioritize Consistency

Return an error (or ask the client to retry) until all replicas agree on the latest address.

✅ Correct data ❌ Lower availability

Option 2 — Prioritize Availability

Respond immediately using the data available on that replica.

✅ Application remains responsive ❌ User may receive stale data

Neither choice is universally correct — it depends entirely on the business requirements.

Real-World Examples

Some systems cannot afford stale data:

• 💳 Online Banking
• 💰 Payment Processing
• 🚚 Food Delivery Order Placement

These typically prioritize Consistency because incorrect data can have serious consequences.

Other systems care more about staying responsive:

• 💬 WhatsApp Messaging
• ❤️ Instagram Likes
• ▶️ YouTube View Counters

For these, slight delays in synchronization are usually acceptable, so Availability is often prioritized.

One Key Learning

One insight I found particularly interesting is that an entire application doesn’t have to make a single CAP decision.

Take Uber as an example:

• Payments → Consistency
• Driver Locations → Availability
• Promotions → Availability
• Ratings → Availability

Different services solve different business problems, so they make different trade-offs.

💡 Interview Tip

If an interviewer asks about the CAP Theorem, don’t simply say:

“You can only choose two.”

Instead, explain that:

Network partitions are inevitable in distributed systems. During a partition, architects must decide whether it’s more important to serve users immediately (Availability) or guarantee that every user sees the latest data (Consistency).

That explanation demonstrates a much deeper understanding than simply memorizing the theorem.