At Zemanta we're happy users of Cassandra for three years now. In all this time I don't remember having any serious issues due to lack of strong consistency in Cassandra. While we run Cassandra in two data centers at most and we therefore rarely experience partitions, we still occasionally observe inconsistencies due to the eventual consistency model used by Cassandra. But due to the nature of our application, which doesn't concern itself with critical infrastructure or financial transactions, inconsistencies are in practice never noticed by our end users nor they cause any hassle for programmers. Since most of other web and mobile applications have similar requirements, I'm pretty sure NoSQL solutions are here to stay and SQL datastores will become niche used only by applications where strong consistency guarantees are really needed. Nonetheless, it's benefical to know that even NoSQL data stores can provide stronger guarantees to programmers regarding consistency if certain conditions are meet. As described in recent article by Bailis and Ghodsi, if a programmer follows a certain set of guidelines (expressed by CALM theorem) on which operations and programs are safe to use in eventually consistent system, he can build a system that is consistent by design while still providing high-availability in the presence of partial failure (partitions). The theoretical findings are slowly trickling also in production systems with Cassandra supporting PBS (Probabilistically Bounded Staleness) predictions since version 1.2.0 and Riak announcing support for eventually-consistent data structures.