In an earlier post (Eventual State Consistency vs. Eventual Path Consistency), I wrote about the difference between two types of Eventual Consistency. While Eventual State Consistency is the more familiar variety, there are applications that require Eventual Path Consistency.
We are of course discussing Eventually Consistent application configurations that relax Consistency in favor of Availability and Partition tolerance per the CAP theorem. If either of Availability and Partition tolerance can be relaxed, Consistency is easily provided, for example, by ensuring that a transaction is committed at the remote instance as part of committing it at the local instance. The case where Consistency can be relaxed is not just more desirable in an “always on” business environment where the competition is just mouse clicks away - it is also technically more challenging (and hence more interesting to a geek like me).
In order to provide Eventual Consistency, an application has to (a) detect when two instances have diverged - i.e., are mutually Inconsistent - and (b) bring them back to a Consistent state.
