>> if you have two nodes that physically cannot communicate but need to be consistent for a client to move forward, the client cannot move forward. Full stop.
> In this setup, a copy of the node is replaceable by taking a (potentially days old) backup copy of it and replaying the events that happened since the time the backup was established.
The replaced node does NOT have access to the events that happened after the partition.
* If the replaced node serves up stale data anyway, you built an AP system.
* If the replaced node refuses to serve up stale data, you built a CP system.
* If you're pretending it has access to the latest events, there's no partition and you built a CA system.
No. CAP requires linearizability for its definition. If your consistency-model moves with the network's ability to communicate, your strong consistency can progress even if you somehow manage to lose your redundant replicas. This is what the CAP-section is about:
This is the summary:
"In other words: any distributed solution that fits the SQL standard can rightly claim that it scales SQL databases, and Brewer’s model can certainly accommodate a framework for that. His model however, is not the only kind of distributed SQL database that can exist, therefore his assertion that all distributed consistent systems must pick where they position themselves on his famous triangle is wrong. The system we explain here for example, is an exception. Formally: because our consistency model stays within the bounds of what the SQL standard allows and includes network communication; and informally because we can fine-tune latency variability according to the use-case of the specific datastore within the system and can even be reduced to only be a theoretical concern."
> This section discusses some failure modes (the first one is about the failure of a specific node): https://itnext.io/how-simple-can-scale-your-sql-beat-cap-and...
> In this setup, a copy of the node is replaceable by taking a (potentially days old) backup copy of it and replaying the events that happened since the time the backup was established.
The replaced node does NOT have access to the events that happened after the partition.
* If the replaced node serves up stale data anyway, you built an AP system.
* If the replaced node refuses to serve up stale data, you built a CP system.
* If you're pretending it has access to the latest events, there's no partition and you built a CA system.