All this requires new ways of thinking. With performance and availability emerging as paramount considerations, you need to make some changes in how you deal with such matters as the consistency of your data and how you build the data model itself. One way to enable this paradigm shift is to address top five misconceptions that relational-minded developers and DBAs believe about ACID compliance for modern applications.
The confusion often starts when I call a postrelational database such as Apache Cassandra "transactional" in nature. One of the first questions I get is: "Oh, is it ACID compliant?" Or a common variant of the question: "But Cassandra is eventually consistent, so it can't be ACID compliant, right?" Both betray a misunderstanding of how modern databases are solving the challenges around online applications.
Misconception No. 1: You can't build an online application without ACID compliance
This misconception is flat out wrong and largely stems from built-in biases that we RDBMS folks have developed over the past two decades. Fortunately, you can easily find hundreds of companies such as eBay, Instagram, and Netflix building mission-critical online applications without full ACID compliance.
Misconception No. 2: ACID is an all-or-nothing proposition
Many people forget that ACID is an acronym representing four distinct characteristics: atomicity, consistency, isolation, and durability. In today's world of online applications, developers and architects make trade-offs to serve the greatest need.
Modern NoSQL databases offer various pieces of ACID that serve the needs of a given application just fine. Postrelational technologies often sacrifice consistency for performance reasons, while following (at least partially) the "AID" aspects of ACID. That's what I mean when I say it's not an all-or-nothing proposition. Parts of ACID may still remain relevant for your application, so you optimize for those accordingly.
Misconception No. 3: Eventual consistency violates the "C" in "ACID"
A few years ago, I wrote a blog post to address this misconception more thoroughly, but the gist is that for many DBAs, the word "consistency" has two very different meanings. "Consistency" in ACID refers to the enforcement of constraints or rules for a given entry in a database. When we talk about eventual consistency in a database such as Cassandra, we mean something entirely different -- namely, the temporal accuracy of the data itself.