The CAP Theorem in Distributed Databases
As part of my journey into understanding distributed databases, I encountered a concept that fundamentally shapes how these systems are designed: the CAP theorem.
It was so eye-opening that I decided to document and share what I learned today.
What is the CAP Theorem?
The CAP theorem states that in any distributed system, you can guarantee only two out of three desired characteristics:
- Consistency (C): Every client sees the same data at the same time, no matter which node they connect to.
- Availability (A): Every request receives a response — even if some of the nodes are down.
- Partition Tolerance (P): The system continues to operate despite network partitions or communication failures between nodes.
Since network partitions can (and eventually will) happen in any distributed system, Partition Tolerance is non-negotiable. Thus, distributed databases must prioritize between Consistency and Availability when a partition occurs.
Types of Distributed Databases Based on CAP
- CA databases:
All nodes remain consistent and available as long as there’s no partition.
However, if a network partition happens, the system may crash.
Examples: PostgreSQL, MariaDB - CP databases:
Prioritizes consistency even during partitions — meaning some nodes may become unavailable until the partition is resolved.
Examples: MongoDB - AP databases:
Prioritizes availability at the cost of consistency.
During a partition, nodes may continue serving potentially outdated data to ensure availability.
Examples: Couchbase, DynamoDB
Reflection:
Learning about CAP helped me better appreciate the trade-offs that engineers must consider when designing distributed systems. It’s all about understanding your system’s priorities — consistency, availability, or how you handle network failures.
#DistributedSystems #CAPTheorem #DatabaseDesign #TodayILearned #SoftwareEngineering
