> But practically speaking these are rare; add remote clients to the monolithic Oracle server and you get a distributed system which can experience a network partition (e.g., the Oracle server becomes unavailable).
The P refers to partitions between nodes of the database system. Not clients.
So that point in the article doesn't seem to make sense.
You don't get nothing, you get inconsistency that could require even human intervention to fix. For example, if client lost connection right before the database was able to respond that his commit was successful. Client then retries and you get a typical double billing problem.
That's because monolithic database with a remote client is in fact a distributed system and strong consistency in a distributed system requires proper distributed algorithms and protocols, where clients are nodes too. You cannot guaranty consistency otherwise (to be precise, you will need clients to be able to wait indefinitely to guaranty strong total consistency, but if clients are used by humans they will not do that and the only consistency you can guaranty for a human is eventual consistency).
But that doesn't really help me understand why CA can't exist. There are still systems that simply don't have network partitions. SQLite on the same phone as the app using it? As I said, it doesn't seem like we ignore the rare or uninteresting cases.
Single-node "CA" systems are "available" under CAP's definition but not available under the common sense definition. A single hardware failure will take out the entire system (but in theory everything will be in perfect order after you restore from backups).
But as soon as you have replication...you have distribution, and what happens when a partition occurs, where the master can no longer talk to the replica(s)? That's where CAP applies; the system -will- make a decision about what to do, and in doing so will trade availability for consistency, or consistency for availability, for any given read/write scenario.
These systems do not guaranty neither consistency, nor availability during network partitions.
> Some systems cannot be partitioned. Single-node systems (e.g., a monolithic Oracle server with no replication) are incapable of experiencing a network partition. But practically speaking these are rare;
I'm not sure how the writer came to the conclusion that these systems are rare. The website I'm working on now has a single monolithic Postgres server, and the majority of systems I've worked on connected to single monolithic datastores, so at the very least these systems exist. These aren't particularly interesting examples, but when talking theoretically like with the CAP theorem, you don't get to just ignore the rare or uninteresting cases. These seem like relatively common examples of choosing CA.
Of course, when you try to shard such databases, you're going to run into serious problems.
I guess the claim I can credit to the author is that CA really really really means no partition tolerance. Even one network partition puts you in CP or AP territory. But I don't think that means CA stores don't exist.
It may be that I'm just not understanding things correctly, though; the CAP paper is definitely a challenging read for me.