This is a paradox that every RDBMS guy thinks that the sky will fall without ACID, but most NoSQL guys happily deploy and support end-user applications without even thinking that "my application will be better with ACID." Unlike Marc B's answer, NoSQL databases are not databases in which updates are accidentally lost or data is accidentally corrupted. The main difference is that in NoSQL databases you use limited versions of atomicity and isolation, etc., But to perform transactions of arbitrary complexity, an exponential amount of effort is required.
There is no reason why you cannot implement a banking system using a database other than ACID. Most NoSQL databases allow you to use micro-transactions that subtract money from one account and add it to another, with a 0% chance of changing the total amount of money in the system.
To discuss this issue in the context of real-life examples, I will describe our application. My company sells software in high school, primarily for scheduling, as well as roll-call voting, managing absenteeism / replacement of teachers, excursions and booking rooms. Our software is based on our own advanced database engine, other than ACID, called Mrjb (available only domestically), which has limitations specific to NoSQL databases.
An example of the difference between an ACID and a NoSQL related to an end user is that if 2 users try to mark the same throw exactly at the same time, there is a (very) small chance that the end result will be a combination of data. submitted by both users. The ACID database ensures that the end result is either one user information or another, or it is possible that one user update fails and returns an error message to the user.
In this case, I do not think that our users will care about whether the status of the "absence" of individual students corresponds to one user update or a combination of them, although they would be concerned that we assigned absence statuses that are contrary to the input of both users. This example should not happen in practice, and if it does, then this is a "race condition", where there is practically no right answer about which user we consider.
A question was asked regarding our Mrjb database about whether we can implement such restrictions as “should not allow the Student object to exist without the corresponding family object”. ("C" in "ACID" = consistency). In fact, we can and support this limitation - another example of micro-transaction.
Another example is downloading a new version of the cyclic school curriculum (usually a two-week cycle) on which the daily curriculum is based. It would be difficult for us to make this update operation atomic or to allow the execution of other transactions separately from this update. Thus, we basically have the choice to either “stop the world” while this major transaction is taking place, which takes about 2 seconds, or allows us to exclude that the student prints out a schedule containing a combination of data for the preliminary update and after the update (there are probably 100 ms in which this could happen). The option to “stop the world” is probably the best option, but in fact we are doing the latter. You can argue that a mixed schedule is worse than a preliminary update, but in both cases we need to rely on a school in which the process notifies students that the schedule has changed - a student working outside an outdated schedule is a big problem, even if it's an agreed schedule . Also note that students usually view their schedule online, in which case the problem is greatly reduced.
I also wrote a “file system-based Blob database” for http://brainresource.com to save their brain scans. This is an important database, and it does not have ACID properties, although they use RDBMS for other data about their subjects.
For reference, our company is described here: http://edval.com.au and our NoSql technology (described as a technique) is described here: http://www.edval.biz/memory-resident-programming-object-databases . There was concern that this post was spam, making it possible to connect to our company, but I would say that (a) the theoretical question cannot be answered only - you need examples from the real world and (b) any retention identifying information about the technology of the product or the database is not suitable.