CAP theorem and consistency trade-offs in distributed systems
CAP theorem, consistency, availability, partition tolerance, CP vs AP systems, eventual consistency, strong consistency, PACELC model, practical examples
CAP theorem and consistency trade-offs in distributed systems
The CAP Theorem
In a distributed system, you can guarantee at most two of three properties simultaneously. Partition tolerance is not optional — network partitions happen in any distributed system. The real choice is between Consistency and Availability during a partition.
CP Systems: Consistency over Availability
During a partition, a CP system refuses to serve stale reads — it returns an error rather than incorrect data. Examples: HBase, MongoDB with strong read concern, ZooKeeper. Use for: financial transactions, inventory, anything where wrong data causes business harm.
AP Systems: Availability over Consistency
During a partition, an AP system serves potentially stale data rather than returning an error. Examples: Cassandra, DynamoDB, CouchDB. Use for: social feeds, user profiles, shopping carts — where slight staleness is acceptable but unavailability is not.
Eventual Consistency in Practice
Most AP systems offer eventual consistency: given enough time, all nodes converge to the same value. The inconsistency window is typically milliseconds to seconds. Design your application accordingly: show last updated X seconds ago rather than implying freshness, use optimistic locking for conflict resolution, and design UIs that degrade gracefully when reads lag writes. Real systems like Spanner offer tunable consistency at a latency cost.