Hacker News Reader

Comment by Chickenosaurus | Hacker News Reader

I think the PACELC theorem [1] should be preferred to the CAP theorem as it is more precise. It states in case of a partition (P), there is a trade-off between availability (A) and consistency (C). Else (E), there is a trade-off between latency (L) and consistency (C).

[1] https://en.m.wikipedia.org/wiki/PACELC_theorem

View on HN

Ah, much better, I have to say. Much more informative as well. The CAP theorem is a bit ungainly since the only way to have a CA database is to only have a single node.

> the only way to have a CA database is to only have a single node.

I know that this is meant to mean: in the real world you cannot just write off partition resilience and still call your system highly available, since partitions will happen sooner or later and when they do your CA system won't be available.

But in the other hand, having a system that is always available _except_ during a network partition is a useful thing: you can design a network where partitions happen much rarely that the rate at which individual machines die.

I.e. in practice a single node, while if you nitpick is the only true CA, will available for less time in average than a multi node CA system which if you nitpick is not CA (provided that the underlying network is partition resilient; it's not a boolean, it's a probability)

(See Google spanner)

It's my understanding that Google Spanner is leveraging hardware (direct lines between machines), so the degree at which there is a network partition is different than compared to other systems.

According to a paper by Eric Brewer, the author of the original CAP theorem, Google Spanner technically is not a CA system [1]. It is advertised as such because partitons are supposed to be exceedingly rare as the infrastructure is outstanding and a lot of operating experience is present [1].

I believe at the end of the day the CAP theorem is too fuzzy for such discussions.

[1] https://research.google.com/pubs/pub45855.html

Theorems are all well and good, but ultimately the thing that matters is the experience of using the system "IRL" as the kids say. If spanner is up 99.99% of the time, and is consistent at all times, it is probably not going to be the weak link in your software chain.

(Fwiw their slo for multi-regional instances is 99.999%, although I have no idea what their measured performance is against that objective.)

The paper says:

"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."

which I believe is another way to word what I say in my post above.

I agree. I did not mean to refute your point, but to provide more context.

Reply on news.ycombinator.com