CAP theorem explained through one network partition
By Unlearnt
The CAP theorem says a distributed read/write system cannot guarantee both linearizable consistency and availability when communication can be partitioned. The difficult moment is concrete: one replica has accepted a change, another cannot hear about it, and a client asks the second replica for the current value.
What do C, A and P mean?
Consistency here means linearizability: operations behave as though they take effect on one shared copy, in an order that respects real time. If a write finishes before a read starts, the read cannot return an older value, assuming no intervening write.
Availability means every request to a non-failing node eventually completes with a result of the requested operation. It is not a monthly uptime percentage or a promise of a fast response. Returning an error for every read does not satisfy this requirement.
A partition means some nodes cannot exchange messages, even though they may still be running and reachable by their own clients. The theorem considers a failure model in which that loss of communication may persist.
A worked example: two copies of a delivery address
Imagine replicas East and West both store ‘10 Oak Road’ for a delivery address. A network partition stops them communicating. The app still allows a user connected to East to change the address to ‘28 Pine Lane’, and East confirms that the write succeeded.
After receiving that confirmation, the user opens another device that reads from West. West still holds ‘10 Oak Road’. It cannot tell whether East accepted a new address or whether nothing changed. Guessing ‘28 Pine Lane’ cannot work in general: the user could have entered any address.
| Moment | East | West |
|---|---|---|
| Before the partition | 10 Oak Road | 10 Oak Road |
| East confirms the change | 28 Pine Lane | 10 Oak Road; cannot receive the change |
| A later read reaches West | Cannot communicate with West | Must decide whether to answer without the missing information |
What can the system do?
If West returns its old address as the value, the read conflicts with the already-completed write. That execution is not linearizable. If West waits for information that may never arrive, it cannot guarantee that the request completes.
A system designed to preserve linearizability could instead have refused to confirm East's write without sufficient coordination. That moves the unavailable operation earlier; it does not escape the trade-off. CAP does not require every partition to block every node or every operation.
Showing a labelled cached address may be a reasonable product choice, but it is a weaker promise than a linearizable read of the current address. Make the contract explicit rather than calling both behaviours the same guarantee.
A common misconception: always pick any two
‘Pick two of three’ hides when the conflict arises. You cannot prevent a distributed network from failing just by choosing not to want partitions. When communication is healthy, CAP does not require you to deliberately sacrifice consistency or availability.
The choice can also differ between operations. Displaying an old profile photo may be acceptable while confirming an irreversible order needs stricter coordination. These are application decisions, not a universal ranking of database products.
What about eventual consistency?
Eventual consistency allows replicas to converge later, under the system's assumptions about communication and updates. It does not promise that West returns the new address during the partition. A later repair cannot make an earlier stale read linearizable.
If both sides accept changes, recovery also needs a rule for conflicts. The chosen rule may discard a change or require application-specific resolution. ‘They sync later’ leaves that important question unanswered.
What CAP does not decide for you
CAP is an impossibility result under specified definitions. It does not give you a latency target, a complete transaction model or a database shopping list. Kleppmann's critique explains why using the slogan alone to compare real systems can obscure the trade-offs you actually need to understand.
For the delivery app, ask which operation needs a current address, what a stale address would cause, how long a user can wait, and how failures are reported. Those requirements make the theorem useful in a design discussion.
Check your understanding
Optional: apply the idea to a new scenario.
Two replicas store a document title. During a partition, replica A confirms a change from ‘Draft’ to ‘Final’. A later read reaches replica B, which still knows only ‘Draft’. With no further writes, can B guarantee both a linearizable read and completion while the partition lasts indefinitely? Explain why returning an error or syncing later does not provide both guarantees.
Answer with the tutor →Free to start, no account needed.