Apologies - fair enough. I can't quite tell if that is a genuine set of three alternatives or not[0], but I sort of see your point. Couple of unsure places:
> Think ACID. Most systems don't do this because it's expensive/complicated.
Is this true? A lot of systems are built on databases.
> Accurate: Whatever you do has no corrupted state
How does accuracy work if the system is distributed and there's a partition, and two node get different data? Presumably it's reliable if they're different, as accuracy is a different item?
> Fast: You can do whatever you want quickly. Think UDP, or filesystems that don't commit their log journal frequently. Tends not to be reliable or accurate.
Most databases aren't ACID compliant, and even if they can be, they're often used in a non-ACID way.
> How does accuracy work if the system is distributed and there's a partition, and two node get different data?
You don't allow writes during a partition. All nodes (or a quorum) must confirm on each write, and if that fails then a partition is detected. Everything that was accidentally written before you detected partition is thrown away. Usually you just have one writer node for simplicity.
> Fast: > Why wouldn't this be reliable?
If you prioritize reliability you will need a slower method to ensure reliability. TCP is slower than UDP so it can be reliable.
> You don't allow writes during a partition. All nodes (or a quorum) must confirm on each write, and if that fails then a partition is detected. Everything that was accidentally written before you detected partition is thrown away. Usually you just have one writer node for simplicity.
Wouldn't this be done better with a majority/minority approach, where if enough nodes are still communicating then they still work?
> If you prioritize reliability you will need a slower method to ensure reliability. TCP is slower than UDP so it can be reliable.
Agree - that is true in the TCP sense of the word reliable. But in your sense of the word, as I understood it, the TCP/UDP difference is more like "accuracy", is it not? Reliability is more like availability, as I read it in your previous comment.
> Think ACID. Most systems don't do this because it's expensive/complicated.
Is this true? A lot of systems are built on databases.
> Accurate: Whatever you do has no corrupted state
How does accuracy work if the system is distributed and there's a partition, and two node get different data? Presumably it's reliable if they're different, as accuracy is a different item?
> Fast: You can do whatever you want quickly. Think UDP, or filesystems that don't commit their log journal frequently. Tends not to be reliable or accurate.
Why wouldn't this be reliable?