Database Management System (DBMS) / Cap theorem and Master Slave Architecture

Cap Theorem in DBMS

The CAP Theorem, proposed by Eric Brewer, states that a distributed database system can only guarantee two of the following three properties at the same time:

  1. C — Consistency

  2. A — Availability

  3. P — Partition Tolerance

👉 A distributed system cannot guarantee all three simultaneously — it must sacrifice at least one.


You can pick only two sides of the triangle at a time.


🟦 Let’s Understand Each Term

Property

Meaning

✅ Consistency (C)

Every read receives the most recent write or an error. No stale data.

✅ Availability (A)

Every request receives a non-error response — without guaranteeing it's the most recent.

✅ Partition Tolerance (P)

The system continues to operate even if communication between nodes breaks down (network failure).


🧩 Why is Partition Tolerance Always Needed?

Because network failures are inevitable in a distributed system (like different data centers, cloud regions, etc.).

So in reality, CAP becomes a choice between:

➡️ Consistency vs Availability during network partitions.


📊 CAP Combinations

Type

What It Means

Example Systems

CP

Consistent + Partition-tolerant: may sacrifice availability

HBase, MongoDB (with strong consistency), Redis (in Sentinel mode)

AP

Available + Partition-tolerant: may return stale data (no strong consistency)

CouchDB, Cassandra, DynamoDB

CA ⚠️ (Theoretical)

Consistent + Available: assumes no network failure, not realistic in distributed systems

Single-node DBs (like traditional RDBMS, e.g., MySQL in standalone mode)


📘 Real-World Example

Imagine a banking system:

  1. Consistency + Partition Tolerance (CP)

    • Guarantee correct balance, even during failures

    • But system may deny access until it syncs

    • Example: MongoDB in strict mode

  2. Availability + Partition Tolerance (AP)

    • Always respond to users, even during failure

    • But balance might be outdated (read stale data)

    • Example: Amazon DynamoDB

  3. Consistency + Availability (CA)

    • Always correct & available

    • BUT fails when network partition occurs (not possible in distributed setup)


📌 Summary

Key Point

Explanation

🔺 CAP Theorem

Tradeoff between Consistency, Availability, and Partition Tolerance

🌐 Real-world systems

Must tolerate partitions (so tradeoff is between C and A)

🔄 Design decision

Depends on the system's use case (e.g., banking vs social media)


📦 Final Thoughts

  • Choose CP if you need correctness (e.g., finance, banking)

  • Choose AP if you need availability (e.g., chat apps, product catalogs)

  • You can't have it all — CAP forces hard decisions in distributed database design.