16. Consistency and CAP
16.8 What is PACELC?
At the bank: CAP talks about the day the line is cut. But every day, phoning the other counter before each withdrawal adds a few minutes. A bank must also decide: on normal days, do we phone first (consistent, slower) or skip the call (faster, slightly risky)?
In the system: Daniel Abadi's PACELC (2012) completes the picture:
If there's a Partition, choose Availability or Consistency; Else (normal operation), choose Latency or Consistency.
Figure: even with no failures, waiting for other replicas to agree takes round trips.
The "else" part matters more day to day, because partitions are rare but every request pays latency. A strongly consistent write that must reach a replica in another region waits at least one cross-region round trip. With an assumed 120 ms Mumbai–Frankfurt round trip, that's at least 120 ms per write, compared with a couple of milliseconds for a local write.
In Abadi's paper, Dynamo-style systems (Dynamo, Cassandra, Riak) in their default settings are PA/EL: during partitions they stay available, and normally they favour low latency. Fully ACID systems that coordinate every write (VoltDB is one example in the paper) are PC/EC: they pay in latency and errors to stay consistent.
Memory code: "On bad days, choose answer or accuracy; on good days, choose speed or accuracy."