Eventual consistency in plain English

Eventual consistency:

1. I watch the weather report and learn that it's going to rain tomorrow.
2. I tell you that it's going to rain tomorrow.
3. Your neighbor tells his wife that it's going to be sunny tomorrow.
4. You tell your neighbor that it is going to rain tomorrow.

Eventually, all of the servers (you, me, your neighbor) know the truth (that it's going to rain tomorrow), but in the meantime the client (his wife) came away thinking it is going to be sunny, even though she asked after one or more of the servers (you and me) had a more up-to-date value.

As opposed to Strict Consistency / ACID compliance:

1. Your bank balance is $50.
2. You deposit $100.
3. Your bank balance, queried from any ATM anywhere, is $150.
4. Your daughter withdraws $40 with your ATM card.
5. Your bank balance, queried from any ATM anywhere, is $110.

At no time can your balance reflect anything other than the actual sum of all of the transactions made on your account to that exact moment.

The reason why so many NoSQL systems have eventual consistency is that virtually all of them are designed to be distributed, and with fully distributed systems there is super-linear overhead to maintaining strict consistency (meaning you can only scale so far before things start to slow down, and when they do you need to throw exponentially more hardware at the problem to keep scaling).

Think you have an application and its replica. Then you have to add new data item to the application.

Then application synchronises the data to other replica show in below

Meanwhile new client going to get data from one replica that not update yet. In that case he cant get correct up date data. Because synchronisation get some time. In that case it haven't eventually consistency

Problem is how can we eventually consistency?

For that we use mediator application to update / create / delete data and use direct querying to read data. that help to make eventually consistency

Eventual consistency:

1. Your data is replicated on multiple servers
2. Your clients can access any of the servers to retrieve the data
3. Someone writes a piece of data to one of the servers, but it wasn't yet copied to the rest
4. A client accesses the server with the data, and gets the most up-to-date copy
5. A different client (or even the same client) accesses a different server (one which didn't get the new copy yet), and gets the old copy

Basically, because it takes time to replicate the data across multiple servers, requests to read the data might go to a server with a new copy, and then go to a server with an old copy. The term "eventual" means that eventually the data will be replicated to all the servers, and thus they will all have the up-to-date copy.

Eventual consistency is a must if you want low latency reads, since the responding server must return its own copy of the data, and doesn't have time to consult other servers and reach a mutual agreement on the content of the data. I wrote a blog post explaining this in more detail.

When an application makes a change to a data item on one machine, that change has to be propagated to the other replicas. Since the change propagation is not instantaneous, there’s an interval of time during which some of the copies will have the most recent change, but others won’t. In other words, the copies will be mutually inconsistent. However, the change will eventually be propagated to all the copies, and hence the term “eventual consistency”. The term eventual consistency is simply an acknowledgement that there is an unbounded delay in propagating a change made on one machine to all the other copies. Eventual consistency is not meaningful or relevant in centralized (single copy) systems since there’s no need for propagation.

source: http://www.oracle.com/technetwork/products/nosqldb/documentation/consistency-explained-1659908.pdf