CAP and BASE: Choices in Distributed Data
When an application keeps data in two regions, the network link between them can fail. If both sides continue receiving requests, “which value is current?” becomes an important question. CAP describes a limit during such a network partition. BASE describes an approach in which some applications accept temporary differences. They are not two names for the same thing.
Two different consistency questions
Consistency in the ACID article concerns a database transaction satisfying defined integrity rules. Consistency in CAP concerns operations across distributed copies behaving as though there were one up-to-date copy. A system can have ACID database transactions and still need a separate policy for a network failure between replicas.
CAP during a network partition
The formal CAP model asks for consistency, availability, and partition tolerance together. When a partition prevents replicas from communicating, a system cannot guarantee both that every nonfailed node responds to requests and that all successful operations behave like one consistent copy.
So “always pick two of three” is a misleading shortcut. The critical tradeoff arises during a partition: delaying or rejecting some requests on one side can preserve consistency; letting both sides process requests can temporarily produce different results. CAP alone does not summarize a system’s performance or availability at all other times.
A counter in two regions
Suppose a like counter starts at 10 in both regions:
| Moment | Region A | Region B |
|---|---|---|
| Link works | 10 | 10 |
| Link fails; one like in each region | 11 | 11 |
| Link recovers | A merge rule is needed | A merge rule is needed |
If both regions accept the likes during the outage, users may
temporarily see incomplete or differing values. If both
increments are recorded and merged correctly, the shared result
is 12. Simply overwriting one copy with the other could lose
an increment. Saying the system will “eventually be consistent”
does not implement the merge.
A delayed display may be acceptable for this counter. It should not automatically be treated as acceptable for selling the last item or transferring money; tolerable delay and failure effects depend on the product requirement.
BASE and eventual convergence
BASE abbreviates basically available, soft state, and eventually consistent. It describes a design that tolerates temporary differences and propagates updates later. Soft state also allows a replica’s visible value to change through synchronization without a new user request.
For the counter to converge, increments need reliable delivery, duplicate handling, and an explicit merge rule. BASE is neither a database type label nor a proof of CAP. A system may use ACID for local transactions while allowing some replicated views to converge later.
Questions before choosing
- Which operations may show delayed data?
- Which requests must receive a response during a partition?
- How will changes made on both sides be merged?
- How will duplicate or reordered updates be handled?
Answering these from product requirements is more useful than
assigning one broad CP or AP label to the whole system.