How Barclays Avoids Downtime Chaos

Operational Data Store

This is when Barclays came up with the idea for Operational Data Store (ODS) – a data cache sitting between channels and the mainframe, and providing a near real-time copy of critical data. Should the mainframe go down, ODS would act as a stand-in to handle ‘read’ requests for specific use cases.

There were three fundamental design pillars for the ODS. It needed to be a robust, reliable and low-latency mechanism to get out of the mainframe, and it would be an API approach that allows for channel abstraction (internal and external). And it had to be a secure, high performance, easily extendable and highly resilient data store.

The decision to go with NoSQL architecture was made quite easily.

“With this kind of project there are always a lot of very long, technical conversations with lots of different opinions being shared, but one thing most of us agreed on from the beginning was that something like this fits in beautifully with a NoSQL architecture,” explains Chandrasekaran.

The fix

A detailed request for proposal (RFP) was made and the decision was made to go with MongoDB in mid 2015.

Barclays went live with ODS in early 2016 and it has been used in just a few different use-cases. Probably the most important is the ‘transaction history’ use-case, to provide unlimited history with advanced search capability.

“In the past, our customers could only see 300 historical transactions online,” says Chandrasekaran. “It didn’t matter if they had taken place in the past 10 days or the past five years. You could only see a subset of your transactions because we couldn’t store and serve up that much. This was a huge problem for small businesses because 300 transactions probably happen in three days for them.”

With MongoDB, Barclays can now bring up all of a customer’s transaction history and make it available to the channels. This was not so much a resilience issue, but an additional capability.

Barclays has more than 30 months of history stored, with 13 billion transactions held in 114 million documents, and is pumping millions of transactions into storage per day. From the moment a transaction request hits the mainframe it takes 800 milliseconds to get that transaction to our audience.

Another interesting use-case had been ‘balance by text’.

“That makes use of the data store too, so we’re building a bunch of use-cases. We initially set out to resolve the problem of downtime,” he adds. “We then thought that if the data is replicated on the mainframe in near real-time we could use MongoDB as the first port of call for balance check transactions. We flipped it around.”

Now the mainframe is the resilience layer for the ODS. Balance queries are the heaviest transaction Barclays does and, generally, every customer will check their balance every time they log on to the bank’s app.

“If that’s happening five million times per day it’s having a significant impact on your mainframe costs,”Chandrasekaran concludes. “Now the ODS serves up the landing page for customers because the balance we have for them on ODS is literally the balance we have in the mainframe.

“What would have required us to do about 16 look-ups across multiple documents is now one lookup on one document. It’s faster, simpler and extremely cheaper.”

Try our mobile apps quiz!