How CP and AP Systems Work

CP Systems: Choosing Consistency CP systems use leader based replication with quorum protocols like Raft or Paxos. Here's the mechanism: A single leader (primary) is elected to accept all writes. The leader replicates each write to followers and only commits when a majority acknowledges. In a 5 node cluster, majority is 3. If you write to the leader, it must hear back from at least 2 followers before returning success. During a partition that isolates 2 nodes from 3 nodes, only the 3 node side can form a majority and continue operating. The isolated 2 nodes refuse writes and return errors. Clients hitting those nodes see reduced availability, but the system never creates conflicting data. The latency cost is real. If inter region Round Trip Time (RTT) is 50ms, and you need 2 follower acknowledgments, each write takes at least 50ms to 100ms plus disk and processing time. Within a region where RTT is 1ms to 2ms, writes might cost 5ms to 10ms at p99. AP Systems: Choosing Availability AP systems use leaderless replication with tunable consistency, similar to Dynamo or Cassandra. Data replicates to N nodes (commonly 3). Each operation contacts some subset. You configure write consistency W and read consistency R. Setting W equals 1 and R equals 1 gives maximum availability: writes return after just one node acknowledges (typically 1ms to 2ms), and reads return from whichever replica responds first. During partitions, all nodes continue accepting requests locally. If 1 availability zone loses contact with 2 others, clients in the isolated zone still get sub 10ms responses. The tradeoff is temporary inconsistency: writes in the isolated zone won't immediately appear in the other zones. Systems reconcile later using anti entropy repair and version vectors. Google Spanner, for example, achieves 99.999% availability while maintaining strong consistency by adding 5ms to 10ms latency for consensus within a region.