Re:Pick strong consistency whenever possible
by mayank on Tuesday January 16, 2018 @11:31AM
(#16159379)
Hey, appreciate the attempt at clearing things up, but I’m afraid your original comment is still quite wrong.
It looks like you’re conflating a well-defined term in distributed systems with properties of particular database implementations that have nothing to do with eventual consistency.
Nothing in your reply is a necessary property of eventually consistent systems, although some eventually consistent systems may be built with those properties. That is quite a huge difference when we’re in the context of the blog post being discussed.
The grayness of your reply should suggest that perhaps you’re misusing the term, rather than everyone else being “confused”.
> Eventually consistency has nothing to do with data failure; the real-world effect of eventually consistency is stale data, which you can't generally tell is stale.
You're right, that is the highly available distributed part, but it goes along with eventual consistency because if you plan for dealing with stale data then those same concepts protect you from unavailable data.
> I think you're talking about availability, not (eventual) consistency.
Again, the two go hand in hand. Deal with stale data and you've dealt with unavailable data.
> There is nothing preventing you from doing joins in a strongly consistent database.
You misread -- I was saying that with a multi-master key-value system you have to do joins in the app.
> This also has nothing to do with eventual consistency.
Same, I was talking about Dynamo-like systems.