Lesson 8 of 17
16. Consistency and CAP

16.7 What do CP and AP systems look like in practice?

3 min read+10 XP

At the bank: One bank's policy is "no withdrawals until the line is back" (safe). Another's is "pay out up to the last known balance, sort it out later" (customer-friendly, risky). Both are reasonable for different services.

In the system:

CP-style behaviour (consistency first):

  • Coordination services like etcd and ZooKeeper: the minority side of a partition can't elect a leader or accept writes, so it returns errors. That's exactly what you want for leader election and configuration (Chapter 14, section 14.8).
  • A single-leader database whose leader is cut off from the majority: well-designed failover stops the old leader from accepting writes (fencing), so that side becomes unavailable for writes.
  • In the chapter's code, CP mode refuses both the write and the read on a replica during a partition.

AP-style behaviour (availability first):

  • DNS: always answers from cache, even if the answer is old.
  • Dynamo-style stores such as Cassandra and Riak at low consistency levels: any replica accepts writes and reconciles later. Amazon's Dynamo paper describes the shopping cart as the motivating example: never refuse an "add to cart", even if it occasionally means merging two versions of a cart.
  • In the chapter's code, AP mode lets both sides accept profile edits; they diverge and are reconciled when the partition heals.

Many systems are tunable. Cassandra lets each query choose its consistency level; databases with replicas let you choose whether reads may go to followers. So "is X a CP or AP database?" often has the honest answer "depends how you configure and use it".

Memory code: "CP says sorry; AP says maybe."