> 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.
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”.
> In and eventually consistent system, the programmer must consider what to do in the case of data failure.
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.
> When building a user authentication system, who better to decide what to do when you can't access the user database than the person writing the user auth system?
I think you're talking about availability, not (eventual) consistency.
> Also, it means that joins must be done in your application.
There is nothing preventing you from doing joins in a strongly consistent database. Google Spanner supports JOINs for example [1].
> In an eventually consistent system, you know if you created a table scan, because you have to pull back a full table's worth of data
This also has nothing to do with eventual consistency.
[1] https://cloud.google.com/spanner/docs/query-syntax#join-hint...