Withdrawing money from an ATM is an easy enough process that we don’t think too much about what’s happening behind the scenes. If we get our money and the corresponding amount is deducted from your account, no more or less, then all is well and good. But that simple transaction comes with other processes ensuring everything goes smoothly.
One of these processes is updated almost immediately to reflect that withdrawal. But what if something happens, say a network failure, that affects the primary database? Will your transaction be reflected correctly?
But, banks have at least the primary database located somewhere else, called a failover database. With database replication software, the bank quickly copies your transaction to the failover database. If or when the primary database fails, the second one will kick in immediately and take over until the primary one is back on track.
More Customers, More Transactions, More Databases
The scenario above illustrates only one transaction from one customer. But banks don’t have just one customer who performs just one daily transaction. This is why banks always have a secondary but even a tertiary failover database, sometimes even more. Most major banks and international financial institutions have hundreds, if not thousands, of copies of their primary databases to ensure no data gets lost.
The main concern with having multiple databases is that there is more to synchronize. It wouldn’t make sense if your $50 withdrawal is reflected in just one or two databases; this would be not only confusing but also more work-intensive since the system either has to find which databases haven’t been updated and change that one by one or update everything, even those that already reflected the change the first time. Imagine that scenario for millions of customers over hundreds of databases, and you have a veritable data management challenge. Banks need a big enough storage space and a powerful data replication solution to handle high-volume data movement.
Handling Contention with Data Replication
To understand contention, picture two transactions happening at once: you withdraw the last $50 from your account just as your credit card company charges you through an automatic debit arrangement you previously authorized. Will you be able to get the cash, or will the card company get credited with the payment?
With the help of data replication, contention does not present too much of an issue. Copy does generate a lot of traffic within the network, but with the right software and settings, the data can be moved quickly, and the failover database(s) can confirm and reflect the changes in real-time. Speed is critical in banking, whether $50, $500, or $50,000.
Other cases of contention include failed transactions due to network failures and similar scenarios. The machine will immediately notify you that an error has occurred; therefore, your account will not be debited the amount because of that error.
This is just a brief look at the importance of data replication in some of the most basic banking transactions. Other applications of such technology include compliance, such as those mandated by the Federal Reserve, and relationship pricing development to appeal to more customers. The bottom line is that your money is data while you don’t yet possess it physically. It would help if you had software like data replication solutions to properly and securely handle the transfer of this data.
