Hacker News new | ask | show | jobs
by quizotic 3260 days ago
Jim Starkey (founder of NuoDB) is rumoured to have said that any adjective before the word "consistency" is equivalent to the prefix "in" as in "eventual consistency is inconsistency". A bit harsh, and not completely true, but a good warning to a world that increasingly believes eventual consistency is the best way to handle the CAP theorem.
3 comments

I would assume that most people are making an informed decision that eventual consistency is the most palatable compromise for their domain. I don't think people just look at the CAP theorem and think that eventual consistency is a magic bullet that gets around one of the necessary compromises, it literally is one of the proposed compromises.
A lot of the time it's not even really a compromise. This is why it makes no sense to debate about eventual consistency - the implications are entirely situational.

This kind of buzzword is harmful; it leads to overthinking, over-engineering, misunderstanding and a lack of focus on what matters, which is implementing solutions that are appropriate for the current context.

It's also a fallacy (or an artefact of enterprise thinking) that you need to either adopt eventual consistency or not. Modern systems are increasingly webs of loosely connected components and subsystems where some processes may be immediately consistent and others not. This is something that we take for granted most of the time (e.g. a search index is almost always "eventually consistent" and nobody would ever think to question that) until we start talking about the concept in an abstract/contrived fashion.

I agree. Eventual consistency is not consistency. Actually, many NewSQL databases nowadays have achieved strong consistency, such as Spanner, Cockroachdb, TiDB, etc.
It's a great way to achieve shapes of liveness and/or latency guarantees for when globally observable consistency isn't necessary for a given problem.

The problem with many eventually consistent systems is that they're not eventually consistent. They're lossy. They often suffer from a variety of problems that are "lost update" shaped, which keeps them from ever converging on consistency no matter how long you wait.