Hacker News Reader

Comment by rbranson | Hacker News Reader

Sometimes I wonder if the claims made by people that banks require ACID are rooted in any kind of experience or fact.

ACID isn't a banking issue, it's an issue in any database where data integrity is important. Having written administration software for life insurance companies, you can be sure that we designed our software to rely on ACID semantics.

Without transactions, correctly writing the software would have been far more difficult, especially in situations where you need to rollback a transaction that is partially completed because of system errors.

Even Google has admitted that they wish they had built transaction support into BigTable from the start. Instead each internal group tried to create their own hack.

Banks aren't ACID though. You can still deposit a check, withdraw against it, then have the deposit fail later.

How do we deal with inconsistency and failed transactions in the real world? Customer service. (anecdotes stolen from Eric Brewer's distributed coherency talk at a Riak event)

Bingo. Banks aren't ACID at all. In actuality, the datastore of record for internal bank transactions usually looks more like a continuous transaction journal with two account numbers and an amount. The snapshot balance of any account isn't much more than a cache computed value. There are, of course, layers and layers of complex systems built on-top of this, but the actual base of all of it is very simple, old school, batch process technology. The original eventual consistency.

Reply on news.ycombinator.com