Lets say I have $10 in my bank account. The database is replicated in North America and Asia. At the exact same time I do a withdrawl of $10 in N. America and in Asia, meaning that my withdraw would do work on two different copies of the data. How can I be prevented from ending up with a balance of -$10 and $20 in my pocket?

Is it possible to produce the proper result with NoSQL?

(I'm not a database expert, just curious)



Take a look at the views of Micheal Stonebraker here - pages 21 and 22. Stonebraker is both an academic and a serious commercial player in the database world (Postgres, Vertica, Informix, VoltDB inter alia). For your particular question, note his views on banking.

Stonebraker is an advocate of "NewSQL".

NewSQL is a two-pronged approach which addresses both fundamental facets of database processing: OLTP and OLAP.

  • For OLTP (banking, shopping) he proposes in memory, sharded, shared nothing architectures with none of the transactional/buffering overhead of "OldSQL" (that's Oracle, SQL Server, MySQL... &c. to you and me). His offering in this area is VoltDB. Oracle and Microsoft are playing catch-up (with In-Memory and Hekaton)

  • For OLAP (DW) applications he is a fan of column oriented stores - i.e. Vertica (a commerical success he sold to HP).

He says two main things:

  • that ACID is essential for a database system (see the .pdf), and
  • that there's nothing wrong with SQL - high level langauages are good and that NoSQL is basically really a great leap 30 years backwards.

He makes the excellent point that back in the 1970's, there was a debate in the CS/IT world about C versus assembler. Some thought that hand-crafted assembler (think Map-Reduce programmes) would be more efficient than a C compiler's output (think database query optimiser).

As you may have guessed, I'm a big Stonebraker fan.

| improve this answer | |
  • 2
    "NoSQL is really a great leap 30 years backwards" - LOVELY, someone with common sense. If a person advovates NoSql - 95% of the time it means he never understood SQL to start with. – TomTom May 17 '16 at 11:08
  • You might also like this :-) – Vérace May 17 '16 at 11:15

Short answer

In a distributed system, you can't be prevented from simultaneous withdrawals. If you want to prevent simultaneous transactions then don't use a distributed system.


By "distributed system", I mean a system where two or more different components can act without waiting for confirmation from the rest of the system. Two-phase commit is not distributed, because while it might involve physically different systems communicating by passing messages, a transaction still has to wait for confirmation from all members.

I think the correct term for what I mean is "loosely coupled", but DbQuestioner88 used the term "distributed system" in the question, so I used it in the answer.


There used to be a bank in New Zealand whose ATMs would operate when disconnected. If the ATM could not contact the central computer system, it would still allow a withdrawal of up to $40. When it did connect later on, the central system would gather together all of these changes. If the withdrawals meant you were now in overdraft then you were in overdraft, and probably paying some interest.

The bank did this so that you could still get some cash out for things like groceries, taxis home, and small emergencies, even if the computer network was down (which it wasn't often, even in the 80s).

Each ATM would only do this once per account, so if you wanted to abuse it then you had to quickly travel between lots of ATMs, which wasn't cost effective. A few people still abused it but the bank treated this as a cost of providing this extra service. In any case, you still had to pay the overdraft back.

| improve this answer | |
  • And it MAY have made sense in the past - when network connections may have been less reliable. Decent approach. – TomTom May 17 '16 at 11:09
  • 1
    "In a distributed system, you can't be prevented from simultaneous withdrawals." Perhaps you want to clarify. Only when each distributed part of the database can commit changes, even when the network is down. There are distributed systems (using 2-phase commit or 3-phase commit or other ways, eg. bitcoin's blockchain) that do not work like this and you can't have simultaneous withdrawals that will get you overdraft. With the expense of course that you'll have to wait for some (or all) other parts to be notified, before the transaction is committed. – ypercubeᵀᴹ May 17 '16 at 11:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.