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).

Leave a Comment