Imagine an eCommerce platform running across US and EU regions.
There is 1 item left.
Two customers try to buy it.
Then the network between the regions fails.
Now the architecture has a decision to make:
🟢 Protect Consistency
If the region cannot establish the authority required to reserve that inventory, wait or reject the operation rather than risk selling the same unit twice.
🟠 Protect Availability
For something like a product catalog or parcel-tracking read model, continue serving local data even if it may temporarily be stale, then reconcile when connectivity returns.
The important lesson:
Partition tolerance isn't really the choice in a multi-region system. Network partitions will happen.
The architectural question becomes:
When communication fails, which guarantee matters more for this specific operation — consistency or availability?
And one subtle point that is often missed:
CAP does not decide whether US or EU “wins.”
That comes from your ownership model, quorum/consensus mechanism, routing strategy, or business rules.
This is also why I wouldn't simply label an architecture with stateless application servers and one database as “CA.” CAP becomes operationally interesting when distributed copies of state can no longer reliably coordinate.
For architects, the better question isn't:
“Is my system CP or AP?”
It is:
“Which business invariant am I protecting during a partition, and what am I prepared to sacrifice to protect it?”
Top comments (0)