Explain the CAP theorem with a concrete example of what happens during a network partition
Partitions aren't optional in a distributed system — CAP is really about what you're forced to give up the instant one actually happens.
LEARN BY DOINGPut your intuition to work3 steps
Explain the CAP theorem with a concrete example of what happens during a network partition
Use the lesson’s examples and explanation to check your idea.
Personal reflection. Nothing is sent to an AI service.#The theorem, precisely
CAP says a distributed data system can only guarantee two of three properties at once:
- Consistency (in this context: linearizability — every read sees the most recent write, as if there were only one copy of the data)
- Availability — every request to a non-failed node gets a response (not an error, not a timeout)
- Partition tolerance — the system keeps working even when the network drops messages between nodes
The part people misstate in interviews: partition tolerance isn't really a choice. Networks partition — cables get cut, switches fail, cross-region links get congested — whether your architecture "chose" to tolerate it or not. So CAP isn't a menu of three where you pick two; it's a statement about what you're forced to sacrifice the moment a partition actually happens. During normal operation, with no partition, you can have both consistency and availability. The theorem only bites when the network is broken, and at that moment you must pick: stay consistent (by refusing some requests) or stay available (by accepting the risk of returning stale or conflicting data).
#A concrete example: inventory across two data centers
Picture an e-commerce system with a database replicated across two data centers, US-East and EU-West, and exactly one unit of a limited-edition item left in stock. A network partition severs the link between the two data centers — both are still up and reachable by their local users, they just can't talk to each other.
A customer in the US and a customer in the EU both click "buy" within the same second.
If the system chooses CP (consistency over availability): each data center, unable to confirm with the other side that the item is still available, refuses to complete the purchase rather than risk selling it twice — or the system requires a majority/quorum of nodes to agree, and the minority side (whichever data center can't reach enough peers) rejects all writes and returns an error to its users until the partition heals. One customer, or both, sees a "please try again" error. Frustrating, but no one gets charged for a unit that doesn't exist.
If the system chooses AP (availability over consistency): each data center independently completes the sale using only its local copy of the data, because refusing the request isn't acceptable. Both customers get an "order confirmed" email. When the partition heals and the two data centers reconcile, the system discovers it sold the same unit twice and now has to resolve that conflict after the fact — cancel one order, apologize, expedite a restock, whatever the business decides.
Neither choice is "correct" in the abstract — it depends entirely on what's more expensive for that specific business: a customer seeing an error message, or a customer getting an apology email for an oversold item.
#Where real systems land
- CP-leaning systems: traditional RDBMS configured with synchronous replication or a single writable primary, ZooKeeper, etcd, HBase. They typically favor rejecting a request over returning a wrong answer, which fits configuration data, leader election, and financial ledgers.
- AP-leaning systems: Cassandra, DynamoDB (in its default configuration), Riak. They favor always answering, then repairing inconsistency after the fact with mechanisms like read repair, vector clocks, or last-write-wins — which fits shopping carts, session data, and social feeds, where a stale answer is far cheaper than a hard failure.
#Beyond CAP: PACELC
CAP only describes behavior during a partition. The PACELC extension (Daniel Abadi) points out that even when there is no partition, you still trade latency for consistency — a system that wants strong consistency has to wait for a quorum of replicas (often across regions) to acknowledge before answering, while a system that accepts eventual consistency can answer instantly from the nearest local replica. So the fuller framing is: if Partitioned, choose Availability or Consistency; Else (normal operation), choose Latency or Consistency. This is why "our system is AP" or "our system is CP" is really only describing half of its actual behavior.
🧠 Check your understanding
0/1 · 0/1 answered1. During an active network partition, what does the CAP theorem say you must choose between?