NoSQL Database for Banking System [closed] NoSQL Database for Banking System [closed] database database

NoSQL Database for Banking System [closed]


Nathan Hurst has a really good blog posting on the idea behind NoSQL databases. I'll do my best to paraphrase:

A database is typically chosen based-on properties of Consistency, Availability and Partition Tolerance (CAP Theorem). Of course, the CAP Theorem states that a database can realistically only focus on two of these. NoSQL databases need partition tolerance to scale properly, so they end-up sacrificing either availability or consistency. RDBMSs negotiate this problem by choosing consistency and availability, and utilize other means to keep their data partition tolerant (ex: replication).

You can typically see the effects of this at the transaction-level. In RDBMS-land all transactions should be ACID (Atomic, Consistent, Isolated and Durable). NoSQL databases typically do not have strict ACID requirements. In this way, data that is updated via a transaction may or may not be atomic (transaction is either completed to all update locations or rolled-back), may not be durable if the power fails, and may run under the assumption of "eventual consistency."

Therefore "no", a NoSQL database is definitely not a good idea for a banking solution.

You should also note that "NoSQL" database architectures differ significantly by brand. What I've said here is a generalization about NoSQL databases. It is certainly not all-encomapssing.


Before answering this question I would like to give an example:GT.M is a NoSQL Database that provide extreme transaction. which is used in the world's largest core banking system, FIS Core Banking system (ranked #1 by inntron)

So theoretically it is feasible to use NoSQL for core banking systems provided that your NoSQL engine supports transactions.

Source: http://www.slideshare.net/fachrybafadal/nosql-technology


Having worked in the banking industry, I'd be cautious implementing anything but well-tested, "legacy" RDBMS systems or mainframes for core banking purposes (Accounts, SOR, GL, etc). For peripheral systems, like marketing, analytical databases etc, NoSQL is fine, but you'll need to be more specific about your use case to get any sort of a good answer to this question.

Every tool has it's correct use case. Banking is extremely risk averse and conservative.