Aveekshith Bushan:

Hey, good morning. Morning, Sid. Good to have you onboard.

Siddhartha Singh:

Good morning, Aveek.

Aveekshith Bushan:

I'd like to welcome everybody on this webinar titled A Fireside Chat with DBS. The context is about modernizing financial services applications for real-time decisioning. A super exciting topic, especially somebody who's been in this space for a long, long time.

Just as a matter of introduction, Sid, who's fondly called as, he's the SVP of the Central Architecture Team at DBS Bank. He is responsible for the global API compliance across all the projects at DBS Bank. His team covers the design, deployment, discoverability, alerting, and monitoring of the multi-country, multi-tenant APIs.

He also oversees the bank's NoSQL databases and Kafka for messaging. He has over 23 years of hands-on experience in this field, skilled in the latest open source technologies, and he's been building and mentoring teams of developers for a long, long time. He's also been a contributor to Pearson Books where he's helped as a technical editor.

So, warm welcome, Sid. Hope you're doing well. I mean, I know you've been down, like I was, with the COVID bug. Are you feeling better now?

Siddhartha Singh:

Yeah, I'm okay. How about you?

Aveekshith Bushan:

Yeah, not bad man. I realized that this year's bug was much better than the previous years, but still there are a few complications that you might have experienced as well, right?

Siddhartha Singh:

Yeah. Yeah. I hope everything is okay.

Aveekshith Bushan:

Yeah, thanks. Thank you. Good to talk again. I'm happy that things worked out well. But anyway, to start with, Sid, I mean this is an interesting topic. Obviously you and me go back a long way. We've had a number of conversations in various organizations as well, but one thing that's... And obviously DBS as an organization is something that the entire industry looks up to in terms of being cutting edge and in some sense leading the race in terms of technology adoption. So just from a context for the audience out here in 2021, there was a whole bunch of stuff that happened, COVID notwithstanding and so on. What are the key things that you folks worked on in 2021 that you can share with the audience?

Siddhartha Singh:

Yeah, the main target, a good question Aveek, so the main thing which we are looking is to reduce MIPS from core banking side, which is like mainframe and all because the charge is high cost, is high business needs, low cost software services and is scalable. So from both the angle, the legacy systems are not that highly scalable also, and it is very costly. So the challenge here is how to scale, because DBS is going to multiple countries. They have a huge number of client base. Almost all 90% of the user base from Singapore is in DBS, probably more. So the challenge is to scale, mainly.

Aveekshith Bushan:

And that would be a priority for 2022. I mean, in fact, interestingly this topic of real time decisioning is very close to my heart as well. What you're finding is not just in the banking space, but in some sense across industries you got Telco, you got the online space as well. It's all about saving that fraction of a millisecond. You talked about scale, but I think scale is one dimension.

Another dimension is how do I... I mean for you to make a real time decision as to whether to maybe upsell, cross sell something to a user or maybe take a real time vision as your driverless car is buying on the road. It's all about every millisecond you save is going to help you with the right decision. So I think that is also, from what discussions I've been having in industry, that is becoming very critical when it comes to real-time decisioning. And systems which can help that, the larger ecosystem, would be highly beneficial for customers to adopt or for banks and other industries to adopt. Is that something that you're seeing as well as a trend from a real-time decisioning standpoint?

Siddhartha Singh:

Yes, yes, yes. Very well pointed out, Aveek. So there are many, many, many systems which can help here. But one thing we found very good with Aerospike specifically is it's a intelligent database also. It's not only NoSQL, it's intelligent, it can scale, it supports real time querying, queries fast. So sub millisecond kind of thing, which we want during real time. When a user logs in, even before that, we want some of the transactions to be seen. All those things we want to achieve using latest softwares. So this is where we are utilizing all the new tech stack like Aerospike also.

Aveekshith Bushan:

Got it. And I think in that sense, DBS bank has always been at the cutting edge in terms of adoption. But three and a half years back or four years back when you started using Aerospike, it was very clear that technology adoption wise in general, not just with Aerospike but in general, you're looking at it from the next four years, five years, 10 years, timelines perspective. So that's very interesting.

Another area which we are seeing a lot of Sid, especially in the banking space, more so in India and you've been in this space, I thought I'll get your thoughts. So what is happening here is a regulator is going after banks which have any kind of downtime. I mean non-availability of the system, especially when you deployed your platform on, say on a third party data center, that is something which a regulator is going after these banks. And there's a huge fines that are imposed of them and so on.

So having the systems running 24 by seven in an active active mode with literally zero downtime becomes very critical for them, for some of these larger financial institutions. That will also mean mainframe augmentation, modernizing your tech stack and so on. Is that something you're seeing as a trend in Singapore or in the market as a whole, or is it something specific you think in India?

Siddhartha Singh:

No, I think this is the architecture to go. Nobody can have any even active and how to stand by logic also. People must have active, active setup and this is where we are utilizing the databases like Aerospike also where we have no downtime architecture. So cross data center replication and all, we must need real time both way, not the typical RDBMS approach where one master and then you have to have another slave. So both way we should be able to treat both the data center, multiple data center, not only two to provide real time transactions.

Aveekshith Bushan:

Got it. And you also alluded to active active and multiple sites., and one of the key technical architectural things that is being discussed now is when you set it up across data centers, would sync replication be popular, would be async? Do you have any thoughts on that?

Siddhartha Singh:

Well, challenges. This is a typical challenge with sync replication, although will be good. But we have chosen a consistency within the cluster, but cross cluster sync replication is something which is not that mature and it will introduce latency. So we are okay with async replication between clusters and data centers. But within the cluster, yes, we are looking for consistency for availability.

Aveekshith Bushan:

Got it. Yeah, so like you said, it's an architectural trade-off, latency versus consistency and so on. And obviously in a distributed system, generally the trade-off is between availability and consistency. A lot of systems are built in such a way that you go for consistency, but then you lose out on availability.

Now for DBS bank, given that your customer base is so huge and you have a large digital clientele, how important is this trade-off and what are your thoughts on that? I mean, given that there is this inherent trade-off that nobody can circumvent if you will, architecturally, how do you look at that?

Siddhartha Singh:

Yeah, again, this is really a good tech question. So of course places where the system is not transactional we go for AP availability based feature. And places where we need primary source of tools to be, let's say Aerospike, then at that time we cannot have availability oriented. We need a consistency base, so we get both of it in one database only.

Aveekshith Bushan:

So what you're saying is depending on the use case, you pick and choose what is the right one, right mode to run the particular data platform and obviously you get that ability to choose which one you want. Now, related to that, one of the questions I have is, and this is something which a lot of the audience would have is... And you've done this not just in DBS bank, but before you started off in DBS bank, a number of applications that you've built in your career.

One of the key questions that a lot of these financial organizations especially ask is, I'm right now on a relation system which is working great, but I need to modernize it. It could be Aerospike, whichever data platform, it doesn't really matter. In terms of your experience when they look at modernizing their tech stack, you had to consider migration. They had to consider how do we deal out the data? Do you have any thoughts?

I mean, how do they approach it? How do these banks approach migration from their existing platforms to something more modern? What kind of a timeline should they look at and how do they start approaching this? If you can share some thoughts to the audience who are largely from a banking perspective, that would be great, Sid.

Siddhartha Singh:

Okay. So yes, the migration of a transactional system is tricky, not easy. You need to build eventing system from the, because it has to be a [inaudible 00:09:58] way. You cannot just switch it on another system to say that migration will be done at runtime, realtime. Realtime data migration is tricky, but one good thing about Aerospike also is they provide connectors. So from the existing legacy system, you can have a connector which sends the data back to your database, Aerospike based database, and therefore you get the real time updates in your system.

And basically the first approach should be, must go to your primary source of truth. But the more of your read operation, you can take it out from a scalable database like Aerospike, you will save the more MIPS because it is always more read than write. So this is how any technical company by the way, go for this approach, that first take out the read side because data write is very important. Write has to happen, then only read can provide you the data. For write, a consistency based database is required.

Aveekshith Bushan:

Yeah, so essentially what you're saying is initially you start off with the read workload. And then obviously from a write perspective, if you already have a relation system or existing system which is working great, then obviously you don't want to touch that because it's working great. But you augment it with another layer like Aerospike or whatever and you start taking some of the load that is there on the relation system.

And do you see this as a six month, one year, one and a half year project? Typically, if banks were to look at this kind of a journey, what is the timelines you see typically for this to mature into something that might work for them?

Siddhartha Singh:

Yeah, it depends, actually which part of your... Because bank is huge, lots of transactional things and they're correlated also. So movement takes time and it should take time. Banks are, like I said, it's a transactional system. Transaction maintenance is not the same like dot com companies where things are non-transactional in nature. In bank you have to be very careful that you don't have to disturb the existing transaction, but you take out all your reads faster for better user experience. The timeline as you asked is, I can tell you that it took us nearly a year, from six months to a year.

Aveekshith Bushan:

Okay. And then that is obviously... So when you look at the larger architecture of it, one is the transactional part or what we call as OLTP. Another one is where we talk about the OLAP and really the reporting analytics part of it, which is now becoming very critical central to a lot of organization, not just in the banking space. And that is also to the topic that we're talking about, which is real time decisioning. It's the ability for you to get the transaction data as quickly as you can to your analytics engine and build your ML algorithms on top of it and so on.

That is another thing which is another dimension altogether. It's a completely different area and I'm sure you in your career have done it multiple times as well. Is there anything you can share in that space from the transactional to the reporting and analytics world as well?

Siddhartha Singh:

Yeah. So like I said, that you have to have a eventing system first so that any transactional data can be thrown out to the eventing system. And then from the eventing system, you build multiple layers of your data source. We call it T1, T2, T3, or whatever you can call that. What is the proximity of your data with the real source? Like in computer you have a L1, L2, L3 cache and close to the CPU.

So then similarly, architecture has to be built in that way that the fastest data which can be thrown out from your transactional system should be kept somewhere which is very robust. Then from there, you have to take out to the layer 2 level of caching where you can run your reporting, you can run your analytics system and all. So that is also where we are putting the specific databases meant for these layers.

Aveekshith Bushan:

Got it. And it's always about picking the right tool for the right use case. There's no one size fits all, obviously. Another thing which is becoming very, and this ties back to the original point we talked about, the migrations and existing platform to a newer platform and so on. It's the whole eventing messaging platforms that need to be put in place.

It could be through something like Apache Kafka or even existing JMS platforms and so on. Obviously there's a lot of push towards that. I mean obviously streaming data and so on, which becomes very critical in terms of the architecture that is rolled out as well. I'm sure in DBS and the other companies you work with as well that is also another key aspect of how you architect it for the now and for the future as well, right, Sid?

Siddhartha Singh:

Yeah, yeah, absolutely. Like you said, we have eventing system also to replicate data.

Aveekshith Bushan:

Got it. And in the case of what you're building, you probably use a whole bunch of technologies there as well to, like you said, with the current ecosystem that Aerospike provides to integrate with your existing platforms, which is interesting to hear.

And also just in terms of how you see the market in terms of the lay of the land, there's a whole bunch of database platforms that customers are grappling with today, right? There is, on one hand you have these systems which have been working for a long time, relation systems, which are great with normalized data. It gives you consistency and so on. And then you have these extremely fast data platforms like Aerospike, some of them optimize for SSD and flash drives like Aerospike, which give you performance at scale.

And then you have these platforms which also you can look at small amount of data caching and so on. When you architect solutions with various types of data platforms can you give a sense of how you think through the problem set and solve it with various platforms that you have without alluding to any specific technology as such?

Siddhartha Singh:

Yeah, yeah, cool. Yeah. So we are talking about Aerospike also because this is the discussion on that also. So Aerospike, one of the good thing about Aerospike is persistence. Like you said, the more fast data you want, you need to go to the RAM, but RAM loses the persistency. So choosing a database for a purpose where data can grow and data is persistent, Aerospike kind of database supports better. And since it is SSD and Flash base, so it is much faster also. It provides consistency also. It's not only AP based database, it has a consistency feature.

We are evaluating it and we are going to see that there should not be any data loss in case of partitioning. So the choice of database depends on the use case, as you've said. If it is very volatile data, there's no persistency required, then you can go for a different set of databases.

Aveekshith Bushan:

Makes sense. And obviously we talked about it sometime back as well. The API support that it provides, that database provides also very critical for you. The data is typically very rich in a lot of contexts. So being able to support things like what you would expect, geospatial, list maps and all that, is that also something critical for you in terms the API support that the database has to provide?

Siddhartha Singh:

Yeah, yeah, of course, of course, of course. This is why initially I said that Aerospike is an intelligent database also, which means it supports your multiple data structures. There are other databases also, but I need persistency along with that intelligence also. So that is why the decision was to choose Aerospike also. We have a couple of other NoSQL databases, but specifically I work for this database.

Aveekshith Bushan:

Very Interesting. I think that's great insights, Sid, and thank you so much for sharing it with the audience. Obviously it was a brief chat with you. I always enjoy speaking with yourself, but I think this is a very interesting topic to the audience out here. This is an area which is now, we are seeing a lot of adoption. You want to modernize your infrastructure, you're looking at augmenting your existing infrastructure. How do you do that? What's the path?

So I think some of the insights that Sid shared should be very interesting for you. And also in terms of real time decisioning, how do you get your transaction data to your reporting store and so on is another interesting area that Sid briefly alluded to. With that, without further ado, is there anything else that you had, Sid? Otherwise, thank you so much for this. I think it was very interesting and thanks for insights.

Siddhartha Singh:

Thank you so much, Aveek. Thanks a lot.