In practice, partition tolerance is the most important property to have, since there's no point in having a distributed system if it can't function if any part of the system is down (it has to be fault tolerant).
In practice, partition tolerance is the most important property to have, since there's no point in having a distributed system if it can't function if any part of the system is down (it has to be fault tolerant).
There's no point in having a system if it gives incorrect answers (inconsistent).
In the real world, you have to make tradeoffs.
Partition tolerant is "most important", it's awkwardly factored out of Availability -- "tolerant" is a variant of available. Your system can't be "partition intolerant "just because that means "not always unavailable".
Another way of looking at it is what you imply: "partition tolerant" is a synonym for "distributed".
This is really a question of definitions, no?
If partition-tolerance is a defining property of a distributed database system, then of course they all have it. Plenty of database systems don't have partition-tolerance: non-distributed database systems.
Non-distributed database systems are inherently partition-tolerant because they can not break into partitions in the first place.
You only really want to sacrifice partition tolerance if the precise correctness of your data is not tremendously important. A CA system can always respond and appear correct, but network partitions result in desyncs. I believe this approach is fairly popular in video games, where a CA system for multiplayer can provide each client with a coherent gameplay experience at the expense of things just breaking if a partition forms. Sorry, game over, please try again.
Most serious systems, though, require P.
One potentially interesting example that uses the current fashion of the day could be to compare payment networks. Visa's distributed payments system is CP, which is to say that it's a consistent system and getting a successful response back means your payment has gone through, but you have no guarantee of getting a successful response. The bitcoin network is AP, which is to say that it's a highly _available_ system which will never fail a response (so long as you can reach one node), but getting a successful response is no guarantee that your payment has gone through.
In all cases, the sacrificed letter is not gone, merely imperfect. This does not mean that Visa is not Available, it just isn't _perfectly_ Available. It does not mean Bitcoin is not Consistent, it just isn't _perfectly_ Consistent. It does not mean that your video game is not Partition Tolerant, it just is not _perfectly_ Partition Tolerant.
You can sacrifice any of the three and still have a distributed system, it will just behave differently.
>usually because of networking problems.
In distributed systems, those are the same thing.
If I am a node -- n1, communicating with various other nodes, the only way I can tell if another node -- n2 is alive or not, is sending messages to it and receiving responses. If the network is having issues and I can't communicate with it, for all intents and purposes, that node n2 is down from my perspective n1.
Edit: Also, diverging of state relates to consistency and not partition tolerance.
You can get partition tolerance at the expense of availability,for by refusing writes during a partition.