The CAP theorem, proposed by Eric Brewer, states that a distributed system can provide at most two of three guarantees simultaneously: Consistency, Availability, and Partition tolerance. This fundamental theorem shapes how we design and reason about distributed systems, highlighting inevitable tradeoffs inherent in distributed computing.
The Three Guarantees
Consistency means all nodes see the same data at the same time. When a write completes, all subsequent reads return that written value, regardless of which node services the read. This is equivalent to having a single, up-to-date copy of the data.
Availability means every request receives a response, without guarantee that it contains the most recent data. The system remains operational and responsive even when nodes or network links fail. Users never see timeout errors; they always get some response.
Partition Tolerance means the system continues operating despite arbitrary message loss or network failures between nodes. Network partitions are not optional in real-world distributed systems—they will happen. The question is how your system behaves when they occur.
Why You Can’t Have All Three
When a network partition occurs, dividing your system into disconnected subgroups, you face a choice. Accept writes on both sides of the partition, allowing the system to remain available but potentially accepting inconsistent data (choosing AP over C). Or reject writes on one or both sides to maintain consistency at the cost of availability (choosing CP over A).
You cannot have both consistency and availability during a partition because nodes can’t communicate to coordinate writes. Accepting writes on both sides creates divergent state. Rejecting writes on one side reduces availability. There’s no escape from this tradeoff.
System Classifications
CP Systems prioritize consistency and partition tolerance, sacrificing availability during partitions. Traditional databases like PostgreSQL in their default configuration are CP. When network issues prevent reaching the primary, writes fail, but you’re guaranteed not to see stale data.
Banking systems often choose CP because consistency is paramount. It’s better to temporarily reject transactions than to risk double-spending or inconsistent account balances. The cost of inconsistency exceeds the cost of temporary unavailability.
AP Systems prioritize availability and partition tolerance, accepting eventual consistency. Cassandra, DynamoDB, and Riak default to AP configurations. During partitions, all nodes remain available, accepting reads and writes even if they can’t coordinate, with conflicts resolved later.
Social media platforms often choose AP because availability matters more than immediate consistency. Users accepting slightly stale data is preferable to the service being unavailable. Missing the latest tweet is less costly than being unable to access Twitter at all.
CA Systems would provide consistency and availability but not partition tolerance. Since network partitions are inevitable in distributed systems, true CA systems don’t exist in practice. In systems without network partitions (single-node databases), you can have CA, but that’s not a distributed system.
Beyond Binary Choices
Real systems exist on a spectrum, not in three discrete buckets. Modern systems often allow tuning the tradeoff. Cassandra lets you specify consistency level per operation: choose strong consistency when needed (at the cost of availability) or eventual consistency for better availability.
PACELC extends CAP: if there’s a Partition, choose between Availability and Consistency, Else (when the network is functioning normally) choose between Latency and Consistency. This acknowledges that tradeoffs exist even without partitions: stronger consistency typically requires more coordination, increasing latency.
Eventual Consistency
AP systems typically provide eventual consistency: given enough time without new updates, all replicas converge to the same state. This is weaker than strong consistency but sufficient for many use cases.
Conflict Resolution becomes necessary when accepting concurrent writes to different replicas. Last-write-wins uses timestamps, though clock synchronization issues complicate this. Application-specific resolution logic handles conflicts based on business rules. Version vectors track causality to identify genuinely concurrent writes requiring resolution.
Practical Implications
Design decisions should consider your application’s specific requirements. Financial transactions need strong consistency; choose CP systems or use strong consistency settings. Social networks prioritize availability; AP with eventual consistency works well.
Multi-Region Deployment intensifies CAP tradeoffs. Geographic distribution means network partitions are more likely and last longer. Cross-region consistency is expensive in latency, often hundreds of milliseconds. Most globally distributed systems choose AP with eventual consistency for this reason.
Read vs Write Availability can be treated separately. Some systems provide read availability during partitions while rejecting writes. This allows serving cached or stale data for reads while maintaining write consistency.
Common Misconceptions
CAP doesn’t mean you must choose one guarantee and completely abandon another. Systems make tradeoffs along a spectrum. Many systems behave as CP under normal conditions but degrade to AP during severe partitions to maintain some availability.
CAP applies during partitions. Normal operation often provides better consistency and availability than CAP suggests because coordination is possible when the network functions properly.
CAP doesn’t capture all distributed system challenges. It doesn’t address latency, throughput, data durability, or operational complexity—all crucial considerations in real systems.
Modern Perspectives
Eric Brewer later clarified that CAP is about maximizing uptime, not about static system categorization. Systems should optimize for the common case while having strategies for partition scenarios. Most of the time, networks function well, and systems can provide stronger guarantees.
Bounded Consistency models provide guarantees weaker than strong consistency but stronger than eventual consistency. Session consistency ensures users see their own writes. Monotonic read consistency ensures users never see older data after seeing newer data. These middle-ground guarantees often satisfy application requirements while maintaining better availability and performance.
Choosing Your Tradeoffs
Understand your data’s characteristics and consistency requirements. User profiles might tolerate eventual consistency, while inventory counts need stronger guarantees. Financial ledgers require strict consistency, while comment counts can be approximate.
Consider partition frequency and duration in your deployment environment. Single-datacenter deployments experience partitions less frequently than multi-region systems. The practical impact of choosing CP versus AP depends on how often partitions occur.
Test partition scenarios explicitly. Simulate network failures and verify your system behaves as expected. Many consistency bugs only manifest during network disruption, not during normal operation.
The CAP theorem provides a framework for understanding fundamental distributed system tradeoffs. While it doesn’t capture every consideration, it’s essential for reasoning about consistency, availability, and the inevitable impact of network partitions. Understanding CAP helps you make informed architectural decisions aligned with your application’s specific requirements and priorities.