Eventual Consistency does not violate Consistency in ACID. Why is this a big thing? Because most NoSql engines do not block access to a data record until it has been propagated to all replicate data stores. The majority of NoSql databases have been designed to handle performance of high demand OLTP or OLAP systems with heavy Insert/Update traffic.
In order to get the necessary performance they use a number of persistence servers with data spread across the whole fabric. This is old news. In order to address ACID, most engines addres AD first, I second, and finally C. Where this differs from a relational database, with everything stored in one engine, is that the Consistency in ACID may take some time, milliseconds.
In order to maintain a durable environment, data is often duplicated in multiple nodes making up the data engine fabric. Here is the scenario that causes most people concern. The client waits until it receives a success or failure for their write to the database. This happens very quickly. However, the change has not necessarily been written to all nodes containing the data. It will be written because the service is aware that it needs to be done.
What this means is that if data is retrieved from one of the servers where the change has not yet been updated, the user will receive what is termed a Dirty Read. In most applications, this is acceptable. We don’t need the latest data from the last millisecond. This doesn’t mean that the data is not Consistent in the ACID sense. All the data from the node that has not yet been updated is Consistent. It simply may lag behind another node for a few milliseconds.
Is this acceptable? Certainly a number of large businesses have built their business on the concept. For a more thorough discussion you can check out this article in InfoWorld where DataStax CEO, Billy Bosworth, expands on ACID and NoSql.
Cheers,
Ben