CP vs AP databases: what happens during a partition?

Rooted in CAP theorem: during a network partition, a distributed database must choose between Consistency (every read sees the latest write, but the system may refuse some requests) and Availability (every request gets a response, but it might be stale). CP systems pick consistency under a partition; AP systems pick availability. Partition tolerance itself is treated as a given — real networks partition, so it isn't the choice being made.

The CP/AP label rarely applies uniformly across a whole product. An e-commerce platform commonly runs the shopping cart AP (a brief hiccup shouldn't block adding an item) and the final checkout/inventory-decrement CP (that specific write genuinely can't tolerate a stale double-sell). Many "AP" systems like Cassandra also let you tune consistency per query via quorum settings — meaning the CP/AP label often describes a DEFAULT or an extreme end of a dial, not a permanent, unchangeable binary choice.

It's worth being precise about what CAP theorem actually constrains, because it's commonly overstated. The forced choice between consistency and availability applies ONLY during an actual network partition — nodes genuinely unable to reach each other. Most of the time, with no partition happening, a well-designed system can be both consistent and available simultaneously; there's no theorem forcing a permanent sacrifice of one for the other in normal operation. The popular shorthand "pick 2 of 3, always" is a mis-simplification of a narrower, more useful statement: partitions WILL eventually happen in any real distributed system — that part isn't optional or a choice you get to avoid by careful engineering — and CAP describes the forced choice you must make specifically for the DURATION of that partition, not a permanent architectural ceiling you live under forever.

This precision matters practically: a system doesn't need to decide "I am a CP system" or "I am an AP system" as an eternal identity — it needs to decide, for each piece of state, what should happen in the specific window where nodes can't talk to each other. That's a much narrower, more answerable design question than the theorem's popular framing suggests.

An e-commerce platform's shopping cart service is built AP (Cassandra/DynamoDB-style): if a data-center link partitions, the cart keeps accepting adds and removes on both sides of the partition and reconciles later — refusing to let someone add an item during a brief network hiccup would just lose a sale for no real benefit, since a cart being briefly inconsistent across replicas costs nothing serious.

The SAME platform's checkout-time inventory decrement is built CP, routed through a strongly-consistent store or leader — because during that same partition, letting both sides independently decrement the last unit of a sold-out item would double-sell it, a real, costly correctness failure. Refusing the write until consistency is restored — telling some users "try again" — is the correct trade here, even though it's the opposite choice the cart made one service over. Same platform, same partition event, two deliberately different answers.