The Distributed Database Dilemma
A global e-commerce company faced a problem. Customers from different countries reported inconsistent order statuses.
Sometimes, orders appeared instantly. Other times, updates took minutes. The engineers had to make a trade-off.
They couldn’t guarantee strong consistency, high availability, and fault tolerance all at once. They had to follow the CAP theorem.
What is the CAP Theorem?
The CAP Theorem, formulated by Eric Brewer, states that a distributed system can provide only two out of three guarantees:
Consistency (C) – Every read returns the most recent write.
Availability (A) – The system remains responsive even if some nodes fail.
Partition Tolerance (P) – The system functions despite network failures.
Breaking Down CAP Theorem
Before learning about CAP theorem, it is necessary for us to know about C,A and P in CAP theorem.
1. Consistency (C) – Always Correct Data
Every read receives the latest committed write, ensuring no stale data.
✔ Pros: Reliable and accurate data. ✖ Cons: Can slow down response times, as all nodes must sync.
Example: A traditional relational database (e.g., PostgreSQL) ensures strict consistency.
2. Availability (A) – Always Responsive
The system remains operational even if some nodes fail.
✔ Pros: Ensures uptime and responsiveness. ✖ Cons: Data might be outdated due to delays in synchronization.
Example: DNS servers prioritize availability—resolving domain names even if some servers are down.
3. Partition Tolerance (P) – Survives Network Failures
The system continues to operate despite network partitions (communication breakdowns between nodes).
✔ Pros: Essential for distributed systems spanning multiple locations. ✖ Cons: Forces a trade-off between consistency and availability.
Example: A globally distributed NoSQL database like Cassandra remains functional even if some data centers go offline.
CAP Trade-offs in Real-World Systems
Since partition tolerance (P) is unavoidable in distributed systems, architects must choose between:
1. CP (Consistency + Partition Tolerance) – Strong Consistency
Guarantees accurate data but sacrifices availability during network failures.
Used for financial systems where incorrect transactions are unacceptable.
✔ Example: Google Spanner, relational databases with distributed transactions.
2. AP (Availability + Partition Tolerance) – High Availability
Ensures the system remains responsive but may return slightly outdated data.
Ideal for social media feeds, product listings, and caching.
✔ Example: Amazon DynamoDB, where availability is prioritized over strong consistency.
3. CA (Consistency + Availability) – Single Node Systems
Provides both consistency and availability but does not tolerate partitions.
Suitable for non-distributed databases running on a single machine.
✔ Example: Traditional SQL databases (MySQL, PostgreSQL) without replication.
Choosing the Right Model
Requirement
Best CAP Model
Example Systems
Bank Transactions
CP
Google Spanner, Zookeeper
Online Shopping Cart
AP
Amazon DynamoDB, Cassandra
Local Database Storage
CA
MySQL, PostgreSQL
Conclusion
Distributed systems must balance consistency, availability, and partition tolerance, but they cannot achieve all three.
CP systems ensure correctness but may be unavailable during failures.
AP systems remain accessible but may serve slightly outdated data.
CA systems work only when there are no partitions.
Next, we’ll explore Latency, Throughput & Performance Optimization – Network Latency, Processing Latency.
