Theory
CAP Theorem
📋 Overview
The CAP Theorem (also known as Brewer's Theorem) is a fundamental principle in distributed systems that describes the inherent trade-offs between Consistency, Availability, and Partition Tolerance. It states that any distributed data store can only provide two of these three guarantees simultaneously during a network failure. Since network partitions (P) are unavoidable in real-world systems, the choice effectively becomes a trade-off between Consistency (CP) and Availability (AP).
🏗️ Core Principles & Characteristics
- Consistency (C): Every read receives the most recent write or an error. All nodes see the same data at the exact same time (Linearizability).
- Availability (A): Every request receives a (non-error) response, without the guarantee that it contains the most recent write.
- Partition Tolerance (P): The system continues to operate despite an arbitrary number of messages being dropped or delayed by the network between nodes.
- PACELC Theorem: An extension of CAP that adds the trade-off between Latency and Consistency during "normal" (non-partitioned) operations.
⚖️ Trade-offs: Pros & Cons
- CP (Consistency + Partition Tolerance):
- Pros: Data integrity is guaranteed; ideal for financial and atomic operations.
- Cons: If nodes cannot communicate, the system becomes unavailable to prevent returning "wrong" data.
- AP (Availability + Partition Tolerance):
- Pros: The system is always responsive, even during a catastrophic network split.
- Cons: Different nodes may return different versions of data (Eventual Consistency), which can confuse users or require complex conflict resolution.
- CA (Consistency + Availability): Effectively impossible in a distributed system because you cannot guarantee a network that never fails.
🌍 Real-World Implementation
- CP Systems: Zookeeper, Etcd (used by Kubernetes), and MongoDB (standard config). These are used where data correctness is non-negotiable (e.g., leader election).
- AP Systems: Cassandra, DynamoDB, and Couchbase. These are used for high-scale web features like social feeds, shopping carts, and logging where speed and uptime are prioritized over immediate correctness.
- Hybrid Systems: Many modern DBs allow "Tunable Consistency," where you can choose CP or AP on a per-query basis.
💡 Interview "Gotchas" & Tips
- The "P" is Mandatory: You cannot build a "CA" system across multiple servers. In a distributed world, network splits will happen. The only choice is how you behave when they do.
- Business Impact: In a banking app, choose CP (better to say "System Down" than to allow double-spending). In a social app, choose AP (better to show an old post than to show an error screen).
- Eventual Consistency: This is the hallmark of AP systems. Mention "Read-after-write" consistency as a middle-ground goal.
- PACELC: Mentioning this shows senior-level depth. It explains that even without a network split, you still have to choose between Latency and Consistency.
📐 Suggested Architecture Primitives
- Consensus Algorithms: Paxos or Raft (the engines that power CP systems like Etcd).
- Distributed DBs: Cassandra (AP), MongoDB (CP).
- Conflict Resolution: Last-Write-Wins (LWW) or CRDTs (Conflict-free Replicated Data Types) for AP systems.
Canvas