Eventually Consistency

As proved in Seth Gilbert and Nancy Lynch's paper, it is impossible to provide all three properties above in a distributed service. However, any two of them could be satisfied at some conditions. In a practical distributed system, partition tolerance is normally a must, which means system failure and network partitions always exist. Under this circumstance, we have to choose which one to sacrifice, consistency or availability (either CP, or AP). On the other hand, a practical real life system normally fits the partially synchronous model, sometimes stale data is allowed, as long as we have a time limit of the inconsistency status and some conflict resolution strategies (Weak Consistency). As a special case of weak consistency, eventual consistency means eventually the system will be consistent if no new update comes into the system.

As we can see in the following table, some systems like HBase, MongoDB fall into the CP spectrum, consistence is more important here, others like Cassandra or CounchDB prefers high availability, which means when messages are lost, returning stale data is allowed.

Table 2.1. CAP theorem with examples (of default configuration)

 Example Systems
CALAN systems, RDBMSs such as MySQL, Postgres, etc.
CPHBase, MongoDB, BigTable, etc.
APCassandra, CounchDB, Dynamo, Voldemort, etc.