> This is quite arguable. Before the Computer Era, all businesses, including the whole financial sector did just fine without ACID.

Can you elaborate a bit? I believe that in the pre-ACID world, business processes were much slower, not online processes like today. When you're only really changing data once a day, backups and manual intervention are acceptable options.

> Still, ACID is used only at a local scope.

What do you mean by "local scope"?

ACID is not a way to deal with faster data change. Actually it is totally opposite. The more updates you have and the more online (distributed) you are, the less you want ACID. ACID is extremely latency-sensitive and failure-sensitive. And latency is a problem caused by just plain old physics - this isn't going to get better unless we find a way to make light travel faster than the speed of light ;) And the more distributed and larger your system is, the more frequent failures (like network partitions or servers going down) will happen.

As for "local scope" I meant "at a single business entity". If you look at a banking or online payment systems as a whole then they are not ACID, they are eventually consistent. The are based on two basic principles:

1. write everything down at least two times, so you never lose data

2. updates are incremental, so you never overwrite data

ACID sure is a way to deal with data change faster than once a day. Once you stop passing paper slips and order forms through your company, you can get accurate, up to date information at a human timescale, i.e. on the order of seconds.

Of course when you want stuff to happen at a faster-than-human timescale - or when you just want lots of stuff to happen - an ACID model might not be the right fit.

> As for "local scope" I meant "at a single business entity".

Understood.

My whole point is that ACID is not the only kind of consistency and it is not required to do "get accurate, up to date information at a human timescale". It is just a nice and convenient programming model, but it comes at a cost of availability, scalability, latency and throughput. You can design systems with no ACID data store and if you do it properly they can be just as accurate and up-to-date when everything works properly, but can also degrade nicely when some components fail.

http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on...

http://www.enterpriseintegrationpatterns.com/docs/IEEE_Softw...

> Before the Computer Era, all businesses, including the whole financial sector did just fine without ACID

The standard of the time looks quite ACID-y to me:

https://en.wikipedia.org/wiki/Double-entry_bookkeeping_syste...

Maybe it is similar, but you can implement it in probably any NoSQL store you wish. And it is not just a standard of the time, it is in wide use today, even if the underlyind database system is ACID.