CP, AP, and CA

The CAP theorem is often summarized as “pick two of the three.” That gives three pairs: CP, AP, and CA.

CP: keep consistency

A CP design keeps consistency during a partition, even if some requests cannot complete.

The majority rule from earlier in this chapter is a CP choice. With one primary and one replica, neither side of the partition has a majority, so the primary stops accepting writes. Every write fails until the connection is restored. In exchange, there is never a second primary accepting writes that the first one does not know about.

Purchases are also CP because of a choice from the previous chapter. Shopend confirms a purchase only after a replica acknowledges it. During the partition, the primary cannot reach the replica, so no purchase can be confirmed. We give up availability for purchases rather than oversell the last blue mug or lose a confirmed order. A shopper who tries to place an order gets an error and has to try again after the connection is restored.

AP: keep availability

An AP design lets every running database server keep completing requests during a partition, even if the replicas disagree.

Shopend’s catalog reads work this way. The replica keeps responding to them with the products it last received. Shoppers can keep browsing, but they may see old prices or stock quantities.

We accepted this in the previous chapter, when we sent catalog reads to replicas. An old price on the catalog page does not end up in an order, because the purchase transaction reads prices and stock on the primary.

CA: no partition

CA describes a system that provides consistency and availability when there is no network partition.

A single database server is the simplest case. Before the previous chapter, Shopend had one database server. There were no replicas to disagree and no connection between them to break. While the server ran, every read saw the latest write, and every request got a response.

A partition here means a broken connection between the servers of the database. If there is only one server, there is no partition. This does not mean the entire system is CA. The network connection between the API instances and the database may fail. If it does, the system is no longer available. We are applying the CAP theorem only to our database system.

Partitions will happen in a replicated database. So in a replicated database, we cannot give up partition tolerance. The choice is between CP and AP. When a partition happens, we give up availability or we give up consistency.

One choice per operation

Shopend is not CP or AP as a whole. During the partition, it is CP for writes and AP for catalog reads.

Cart edits are writes, so they stop too. In the previous chapter, we let the primary confirm a cart edit without waiting for a replica. With that choice, we accepted the risk of losing an edit during failover. But that choice does not let the primary accept edits during a partition. In our example, the majority rule still stops it from accepting any write.

To choose for an operation, we ask what it costs to give up each guarantee for that operation. Overselling a mug or losing a confirmed order costs more than making a shopper wait. Showing an old price while someone browses costs less than refusing to show the catalog.