

Eventual Consistency - joubert
http://books.couchdb.org/relax/intro/eventual-consistency

======
houseabsolute
I think the CAP theorem has been overapplied in a lot of cases. All it says is
that the three forces are in tension, and that as you get more of one you have
to trade away some of the others.

But that's pretty obvious. It's true in any optimization problem. There are a
spectrum of technologies available, and all fall somewhere on what for the
sake of argument let's call the CAP horizon. Why is it the case that you have
to trade of one of C, A, or P when transitioning from one of these
technologies to another?

The reason is obvious. Any technology that is _not_ on the CAP horizon must
either improve or die. No one would use a technology that is simultaneously
less C, A, and P than some other technology that's available.

So it's not true that you can only gain in one of the three by giving up some
of the others. It's only true that of the products available that you might
actually select from, all exhibit the tradeoff because if there was no
tradeoff then one of the products would die.

There should probably be a fourth variable. Pr for "price." See Microsoft and
Oracle make databases that are simultaneously as C and A, and more P than
certain distributed solutions in MySql. But there you have to give up some Pr
in order to get that extra P.

This kind of statement (X, Y, or Z, pick two) is an interesting, thought
provoking way to state the tradeoffs in an industry. But it's more of an
economic statement than a technical one. There are probably solutions yet to
be discovered that will push all three variables higher in a single solution
than anything we've discovered so far. But if and when such a solution is
discovered, people will still be saying, C, A, P, pick two, and they will be
right because the tradeoff will still be in effect with other products of the
time.

~~~
russell
The solution is to avoid one-size-fits-all. Some things need to be consistent
and immediately available, e.g payment processing or privacy settings, even if
you have 100 million users. For those use a relational database with only a
few tables. For huge data sets, like billions of social interconnections, use
a noSQL solution that scales to dozens of server locations. Eventual
consistency is good enough, even some never consistent.

------
jrockway
Problem with CouchDB is that there is no eventual consistency if a document
depends on another. They should rename it "inevitable inconsistency".

