[Dylan16807]

It irks me whenever something trying to clarify CAP insists that you can't choose CA. You can. In the real world you can't avoid partitions, but you don't have to tolerate them.

The rule for Availability is that non-failing nodes must respond. If you detect a partition, you can fail the node. Make a system that shuts down when it loses a connection and you can be CA.

[fred256]

Maybe I'm missing the point you're trying to make, but a node that's shut down isn't exactly available.

[Dylan16807]

It's not the one node that shuts down, the whole system flicks a switch and ceases to be. It's incompatible with partitions.

So while you end up with something that's for most purposes worse than CP, it's still a possible configuration.

Availability does not require uptime. It only requires that if you are up, you are fully functional.

[cwp]

This highlights a further asymmetry in CAP. Yes, P is unavoidable if you have a distributed system. But also, availability is a property of the system when there is a partition. If you're not going to tolerate partitions, what does it mean to be available?

[josteink]

> If you're not going to tolerate partitions, what does it mean to be available?

It means you're not running a partitioned and distributed system, but a regular non-partitioned system.

Yes I know distributed cloud object-graph databases on selective-persist elastic firesprout-nodes are very popular and trendy these days, but lots of people just run regular, old-fashioned unpartitioned databases, like pgsql/mysql and they work just fine.

I know. Like whoah, eh?

[redwood]

Good point. Is it theoretically possible to guarantee a node shuts down in time the moment partition is detected? What I mean is: isn't there always a small window?

[Dylan16807]

Depends on what you mean by window.

If you mean a window for that node to act before it realizes there's a partition, your Consistency protocol should prevent that. Anything that requires all nodes to respond should work.

If you mean a window for the node to receive the request, without acting on it, before it fails, that doesn't really matter. From the outside you can't tell the difference between a node that failed before it got your request, and one that failed immediately after. And note this quote:

"Brewer originally only required almost all requests to receive a response. As allowing probabilistic availability does not change the result when arbitrary failures occur, for simplicity we are requiring 100% availability"

Plus, any other interpretation would make node failure fundamentally incompatible with Availability. You will always lose a request that was lodged one nanosecond before node failure.