CAP Applied to Databases

The CAP theorem states that a distributed system can guarantee only two of three properties simultaneously: Consistency (every read sees the most recent write), Availability (every request receives a response), and Partition Tolerance (the system continues operating despite network partitions). Since network partitions are unavoidable in real distributed systems, the practical choice is between CP (sacrifice availability during partitions) and AP (serve stale or conflicting data rather than refusing requests). The PACELC model extends this by considering the latency vs consistency trade-off even without partitions.

Key Points

• CP databases (ZooKeeper, etcd, HBase, Spanner) will refuse reads/writes rather than serve stale data during a partition — suitable for financial ledgers, inventory counts.
• AP databases (Cassandra, DynamoDB, CouchDB, Riak) remain available during partitions but may return stale or conflicting data, requiring conflict resolution (LWW, vector clocks, CRDTs).
• Cassandra's consistency is tunable per-operation: QUORUM (R+W > N) gives strong consistency; ONE gives eventual consistency — not purely AP in practice.
• PostgreSQL single-node is CA (consistency + availability) — but adding synchronous streaming replication makes it CP, as the primary blocks on writes if the synchronous standby is unreachable.
• DynamoDB is AP by default with eventual consistency reads (read any replica); strongly consistent reads (CP) are available at 2x the read capacity unit cost.
• MongoDB with majority write concern + majority read concern is effectively CP; with default settings (primary reads, w:1), it can serve stale data after failover.
• PACELC for Cassandra: PA/EL — during Partition chooses Availability; during normal operation chooses Low Latency over Consistency.
• Linearizability (strongest consistency) requires all operations to appear atomic and instantaneous — achievable with consensus (Raft/Paxos) at latency cost.