Inside Cloud Spanner and the CAP Theorem

This is marked as a dupe, but is it? The "past" link does not find an earlier submission of it.

Is it being mixed up with the earlier submission to the announcement of Cloud Spanner? That article announced it and gave an overview. In that overview it was mentioned that Cloud Spanner does not violate the CAP Theorem even though its feature set might make it appear to.

The present submission is to a different article on the same site that is about the CAP Theorem and how Cloud Spanner achieves its features without violating CAP.

"Does this mean that Spanner is a CA system as defined by CAP? The short answer is “no” technically, but “yes” in effect and its users can and do assume CA. [...] during some partitions, Spanner chooses C and forfeits A. It is technically a CP system. [...] delivers availability that is so high that most users don't worry about its outages"

This is quite confusing, CAP tradeoffs are about what can be provided simultaneously, not the system's availability over time, it's a different kind of availability. I think the tradeoffs in CAP are better explained as __waiting__ to achieve consensus. If you wait for consensus, you can get global consistency, but you would have to wait for it somewhere on some level no matter what every time. Waiting is not good for latency though. So, if you don't wait for consensus, you can pretty much guarantee good latency, but would have to rely on CRDTs for consistency. You cannot really assume CP as CA. You can misunderstand it of course.

Should this discussion be merged with https://news.ycombinator.com/item?id=13644959 ?