Google’s Spanner database is very likely an example of overcoming CAP. There’s more details here: https://ai.google/research/pubs/pub45855. From what i’ve read, Google is able to do this because they control the physical data transfer infrastructure (the nuts, bolts, cables) which in many cases is the reason why CAP is defeated.
>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.
>The purist answer is “no” because partitions can happen and in fact have happened at Google, and during
(some) partitions, Spanner chooses C and forfeits A. It is technically a CP system. We explore the impact
of partitions below.
...
>Conclusion
>---------
>Spanner reasonably claims to be an “effectively CA” system despite operating over a wide area, as it is
always consistent and achieves greater than 5 9s availability.
The jist of the argument is that no DB gives 100% availability. That makes no sense. What if my client can't talk to anything? I'd still have to return a value.
So instead we talk about high availability. All sorts of things cause downtime besides network partitions. If the network is reliable enough, then you can still achieve high availability.
Ive known friends in the South Indian state of Kerala (where the climate is very suited for vanilla cultivation) whose families are struggling to raise Vanilla as an intercrop in their existing plantations due to labour shortfall. As the article states, the main ingredient required here is cheap manual labour without which this venture is doomed to fail.
