When a banking transaction is processed, Account/s involved in the transaction get/s locked for a tiny period. This period starts when the account gets locked for the transaction and ends when the transaction is committed in the database. This locking is a necessary evil, to maintain the integrity in account balance. During this period when the account is locked, if another transaction needs the same account, it will try to lock the same account and it will not be available and this second transaction keeps on retrying to acquire lock on the account, until it acquires the lock on the a/c. This multiple, sometimes hundreds of ‘try to acquire lock’ calls to the Operating system (ultimately all lock requests will land to the OS or to the file system) are one of the main reasons for performance issues in Banking systems and these calls become very ‘heavy’ as the number of current locks become high in an enterprise scale system.
For example, an account getting 10,000 transactions is not available for a period of about 28 minutes. This unavailability of the account and wasted computer resources to handle futile ‘try to acquire lock’ calls are the crux of the problem not properly solved in databases or in Banking System Design.
The solution is in the Idea of Quantum Locks. This means lock an account only for the amount needed in a transaction. If an account has a million-dollar balance and a transaction is to debit the account with USD 10,000, then a Quantum Lock will place only a lock on USD 10,000 on the account. Rest of the balance in the account (USD 990,000) is available for other transactions. It is like creating a multi lane account open to concurrent transactions. If a transaction is to credit the account with USD 100,000 then a Quantum Lock of 0 USD is placed on the account, as this transaction is not going to consume any available balance in the account. Quantum Locks treat the account as a resource that can be depleted or enhanced by transactions.
Current cutting-edge database technologies do not support any other lock of lesser granularity than a Row Lock. In the 80s even lowly languages like Basic used to support field level locks. Quantum Locks are even lesser granular than field locks.
As databases do not support Quantum Locks, a designer can implement Quantum Locks by Design. Absence of Quantum Locks have hugely increased running costs of Banking Systems.
When a module or process is taken out an implemented outside of a core system (Hollow The Core – HTC) & the module handles Corporate Accounts, Group Limits, Real Time GL Balances, etc, then Quantum Lock Implementation along with a Hyper Automation using Bot Workers can be fantastic solution.
We at Patterns Cognitive keep Quantum Locks as a Design Pattern to be used with Hyper Automation Projects that need to automate bulk processing.
