[pkolaczk]

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

[sigill]

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.

[pkolaczk]

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...