We had a healthy lunch table discussion on Consistency Vs. Correctness in context of data stores (ex: relation databases and NoSQL stores). Where many times people assumed that if data store guarantees Consistency, the solution is correct. I came from Database Engine development background can clearly distinguish the difference. But I learnt today over lunch table discussion that how one can interpret the article discussing this domain differently by a non-database-engine developer. Thanks to Mustafa Hussain who made me understand the other way of looking at things.
Coming to the main topic, there was a good article on CAP Twelve Years Later: How the “Rules” Have Changed.
Why do banks have their own Correctness system when Relational Databases provide Consistency?
Banking solution correctness involves many non-database parts. Not just non-database parts, but non-software parts. A simple ATM transaction is not equal to Database transaction. Because, a database transaction involves making sure that ACID properties are adhered to data with in the database. Where as an ATM transaction involves databases, teller machine, physical currency notes, dispenser, unpicked-money-pull-back, currency loading, physical book-keeping, etc. As you can see, by just using database that guarantees Consistency, Banking solution does not become correct. Much more need to be done and hence Consistency != Correctness.
Well, you may then ask:
Why should Financial Banks use costly Relational Databases over cheap NoSQL stores?
I am talking about a case where if brand new financial banking software were to be developed, why should it use Relation Databases over NoSQL Stores.
Note that, I am talking about NoSQL stores that chose to support Availability and Partition Tolerance and forfeited Consistency per famous CAP theorem that the above cited article revisited.
While Availability is important in the ATM scenario author chose to describe in the above cited article, he did not mean to forfeit ‘C’ completely. We still need consistency with in a database in a particular site (ex: ATM room) across rows, tables, etc. For example, money transfer between two accounts using ATM requires the consistency guaranty from data store. NoSQL stores of today do not provide it. Hence, the author cited it as “Another aspect of CAP confusion is the hidden cost of forfeiting consistency” .
So, NoSQL stores have their own strong scenarios but not necessarily they fit for all scenarios. Banking is one such scenario.
As cited article author discussed, when we have NoSQL Stores that support C and A, we can then think of Banking like workloads to move over to such stores.
Laxmi Narsimha Rao Oruganti