In a distributed system, the same piece of data is usually replicated to multiple machines. When you update that piece of information on one of the machines, it may take some time (usually milliseconds) to reach every machine that holds the replicated data. This creates the possibility that you might get information that hasn't yet updated on the replica. In the old relational world, this conundrum comes very close to what we call a "dirty read."
This approach can present its own set of challenges at times, but the point is that eventual consistency is a different issue than the consistency definition you find in ACID. In order for developers to appropriately manage this new dynamic, it's important that they not confuse the two definitions.
Misconception No. 4: Databases and applications have a 1:1 relationship, so it's either/or between relational and NoSQL technologies
Years ago when we wrote applications at much smaller scale, life was easy: We picked a database, wrote our application, and were done. In fact, a single database system such as an Oracle instance would often house multiple schemas that represented different applications.
Today's applications are much more sophisticated. The idea of running a single database technology for a datastore is passé. A few years ago, Martin Fowler highlighted a trend called "polyglot persistence" that is now the normative architecture for modern applications. Virtually every customer I talk to houses a services layer between multiple database technologies and the app they power. This trend has established itself firmly in the real world. Polyglot persistence allows us to use the right technology for the right workload inside an application, which can pay huge dividends and enable functionalities not possible in a 1:1 schema.
Misconception No. 5: NoSQL databases are for "Web scale" applications only; everything else uses ACID-compliant technology
Some people believe that only a niche subset of applications require scalable, distributed databases. If you stop and think about it, how many developers today build online applications that don't keep "Web scale" in mind? It's like saying, "Only a small number of cars require the speeds necessary for highway travel."
That may have been true when only a few highways existed, but now they are part of everyday travel. The same is true for Web-scale applications. Given the always-connected nature of endpoints -- whether they are users, devices, or sensors -- what other kind of online application would you write? When are performance and availability not a high priority?