Hacker News Reader

Comment by StefanKarpinski | Hacker News Reader

tl;dr. "Eventual consistency" is a b.s. marketing term that actually has nearly no meaning.

The easiest way to see just how empty the definition is, is by negating it and seing what undesirable property a system would have to have in order to fail to be eventually consistent. Take the definition from wikipedia:

"Given a sufficiently long period of time over which no changes are sent, all updates can be expected to propagate eventually through the system and all the replicas will be consistent."

Negation:

"No matter how long you wait without sending changes, updates may not propagate through the system, and disagreement may continue to exist between replicas indefinitely."

So basically, saying that something is "eventually consistent" just means "we won't completely ignore you forever". Great.

View on HN

Eventual consistency is definitely weak, but it's useful: if we couple eventual convergence with safety properties, then we can describe non-trivial properties.

The problem, which I alluded to in my first footnote, is that it's hard to guarantee anything stronger than eventual in the presence of partitions. If you want to make sure your system behaves "correctly" under arbitrary partitioning, you necessarily have to admit the trivial cases. What you also want to guarantee is that, in the absence of partitions, the system still "does the right thing"; this often gets lost in the definition of eventually consistent systems, which is why you should consider both safety and liveness.

If you completely understand the weaknesses of eventual consistency you will use is only where it is viable and the risk is justified. There is a reason the relational databases haven't gone away completely.

As a shameless plug, I might add that if you can model your network delays, you can use some modeling like our work on PBS (Probabilistically Bounded Staleness) to predict staleness: http://pbs.cs.berkeley.edu/#demo

I'd also add that the consistency related to ACID semantics from relational databases refers to transactional consistency, not replica consistency. Indeed, distributed RDBMSs often opt for strong (replica) consistency models, but there is no reason a distributed relational database can't be weakly (replica) consistent while maintaining ACID semantics on a single machine. Moreover, if the RDBMS must needs to be available in the presence of partitions, it must be weakly (replica) consistent.

The problem isn't really the term "eventual coincistency" but rather neglecting to define "sufficient time", which needs to be done case-by-case. Something like "ram size divided by the slowest connection between servers, plus 40% margin". That gives you a useful and predictable model that even handles partitions (treat as speed 0).

Reply on news.ycombinator.com