Hacker News Reader

I was making the distinction on being the user VS being the builder of the system. The user doesn't need to know or understand the internals.

> consistency... consistency... consistency

What if I am not aiming for consistency in the first place?

We both understand that "total availability" is mythical. So why not target partial availability in the first place?

View on HN

I'm not saying you should not have availability. On the contrary, many strongly consistent algorithms actually have very good availability characteristics. The whole point of being distributed is often to increase availability. Algorithms like raft and multi-paxos can provide availability so long as a majority of nodes remain reachable to the client, which I think is pretty acceptable in many cases. This is sort of why the availability vs consistency dichotomy is a false dilemma. Sure, having linearizability means you cannot have total availability and vice versa, but generally you can have very good availability and preserve strongly consistent semantics. What I disagree with is that trading strong consistency to achieve total availability is useful in many domains. To be fair, there are some, and for write-heavy workloads that tend to materialize a readable view in the future or for things like immutable caches, it can be extremely useful to weaken consistency, I just have often found that for the bulk of business logic, weaker consistency semantics make unacceptable tradeoffs to users.

Reply on news.ycombinator.com