Traditional banks have typically relied on monolithic core banking systems where all of a bank’s services are bundled into one software application. A major challenge with that is if a bank needs to make changes to a single service e.g. information about cashback offers where the bank has to make amendments in a single codebase that governs the entire application. That is not only complex, but also a super high-risk change; if you make a mistake, you take down the entire system. This results in banks being significantly risk averse when it comes to making changes and therefore they tend to avoid tinkering with the system wherever possible - which is a broader drag on transformation and the reason many banks are still lagging on their digitization efforts.
By contrast, cloud-based core banking systems that are built using an event-driven microservice architecture enable banks to make changes faster and with less risk. That is because microservices effectively divide a bank’s services into independent chunks - so everything related to current accounts or loans or mortgages and whatever it might be, will all be designated as standalone services. Therefore, if a bank needed to make changes to its cashback offers, it would only need to change the code relating to cashback offers. That means if something went wrong, it would only impact that individual microservice and not the core banking system, minimizing the potential blast radius. This creates a more controlled change environment and helps banks become more nimble when innovating or simply updating the system.
The reason why event-driven microservices are superior to standard microservices is because those services don’t need to be hardwired to the core banking engine. With standard microservices, which are hardwired, everything is connected, creating a ‘distributed monolith’ that is like a house of cards - if you change one thing, the whole system collapses because of the hardwiring. With event-driven microservices, those microservices simply subscribe to whatever data they need. If 100 microservices need to access transaction data, in the old world that would mean having 100 hardwired connections going into the system to retrieve that data. Now the data just needs to be published once to an event and all of those 100 microservices will simply read the published data.
This article is an extract from our whitepaper "The Power of Data". To read on, please download the full whitepaper via the button below.