Hacker News Reader

> I think you're misunderstanding what the problem is here. I want global consistency (really I want two party consistency) to prevent the said user from witnessing the unkind thing I posted about them.

You don't want global consistency and you're saying it yourself.

What you want is to be presented with a view that is consistent with the actions you've done. [it's really basics101 for user experience.]

The internals of the system don't matter to you. It only matter to us, as the builders. We can make it so that it is internally 'inconsistent'[0] yet it always presents a 'consistent'[0] view to the user.

[0] I don't think the word consistent describes well the situation. Nothing is ever strictly perfectly consistent.

You seem to be assuming that I'm a UX designer. I'm not, I'm a backend engineer. Just a note though: I wouldn't say something like "The internals of the system don't matter to you. It only matter to us, as the builders." to a UX designer, since that's super condescending.

Sequential consistency is basically the most lax model you can get away with in this case (and have it generalize to other similar operations). This is a very strong consistency model and weakening linearizability to this basically provides no advantage for availability. There is a proof that anything stronger than causal consistency cannot provide "total availability", which I'd argue is somewhat mythical anyways (except when you're colocated with where data is being stored).

My point here is that this is clearly a case where many of the strongest ordering guarantees are required to get the desired behavior, and subsequently availability must be sacrificed.

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?

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.

> It's necessary that my own actions appear in their original order to me, but also to anyone else who is plausibly affected by their reordering.

No, it's necessary that the effects appear in the right order, and in the example case what matters is that the privacy setting is correctly applied to the subsequent post and stored with it.

> The full example also involves posting on a mutual friend's wall and having that post hidden by unfriending

If that is a requirement - and it's not clear it would be a good user experience, as it would break conversations (e.g. any reply; and what do you do about quoted parts of a mssage) and withdraw conversation elements that have already been put out there -, but in any case this does not generally require global consistency. It does require prompt updates.

Do you really need global consistency for that? I think you can get by with user-consistent ordering as long as your data model's right.

It sounds like you're saying that the friend-state for a given post are part of the permissions for the post, and therefore part of the post itself. In which case, when a user posts, I'd include the version number of their friend-state in the post's permissions. Then on view attempts, I make sure that the friend-state I'm working with is at least as new as the friend-state referred to by the post.

There are definitely solutions for handling this with consistency semantics that are something weaker than linearizable consistency. But they usually become expensive in other ways and loose a lot of the availability benefits to recover the consistency properties you do need. Most of the models we're even talking about here are something in the realm of sequential or causal consistency, which are still considered strong consistency models (and are usually implemented on top of linearizable algorithms that allow for weakening invariants that protect against witnessing inconsistency. spanner is an example of this).

Your friend-state solution only protects the visibility of the post if the friend-state between the two users has not changed more recently than both the post and your version.

I.E.

Friend state 0 is we're friends.

Friend state 1 is we're not friends.

Friend state 2 is we're friends.

Friend state 3 is we're not friends.

I have friend state 2, and the post is at state 1. I accept my version incorrectly and am able to view the post, despite the fact that we're no longer friends.

Do you perhaps have a different example that might make the problem more apparent here? Because if I post something you don't want to see, give you permission to see it, and then take it away again, I can live with you seeing it. I probably won't even know if you saw it because there was some sort of system glitch or if you just happened to look during friend state 2.

I'm seeing a lot of comments that are basically saying, "we don't need no stinking transactions because we can mostly reinvent them in the app." And the point of the article was, yeah, or you could pick a solution that already solves this.

Was that the point of the article? I didn't read it that way. E.g.: "In conclusion, if you use micro-services or NoSQL databases, do your homework! Choose appropriate boundaries for your systems."

You are right. The article says to understand your choice, it doesn't say WHAT to choose.

Pretty sure the subtext is that developers are making their lives harder than they need to by not understanding the choice they are making.

> I want two party consistency

aka snapshot consistency.

(Thoroughly enjoyed your "the user is sort of the unstated extra party in a distributed system", btw.)