 Okay, good morning everyone My name is Alok Madhukar, and I'm joined by my colleagues Subramaniam Ramurthy and Rishabh Maheshwari, and we are from Goldman Sachs, Bangalore So today we are going to present How we are using foundation DB in financial services. So There's a mandatory disclaimer Okay, so We have been using a system called sec DB. It stands for securities database and it was built in 1991 so it's been 28 years and There are some numbers here's which kind of signify the scale of the operations that we have So the system has been running stable for over 28 years now and at this point we wanted to You know evaluate how we modernize the plant So to give some background Like why we built a system like sec DB and what were there some of the design decisions made? So what we wanted from a data platform was that our trading is happening in All the countries roughly 160 different locations. So you want to capture the risk artifacts across all these locations So the throughput needs to be very high. So these Businesses can be equities or foreign exchange So these are very kind of high throughput environment. So we need to kind of roughly Let's say capture 3 billion trades happening in a given location and Then we want to have real-time risk, which means that if a trader books some trades in Tokyo And a trader in New York is working on the same account. He should be able to have real-time risk on the system And then we are kind of regulated a highly regulated environment. So we need quick reproducible tree of results Which means that we may be asked to go back in 10 years and explain why a certain price was arrived and then We are in a scenario where we actively need to kind of do what if analysis what if some governments go down? What if market conditions change? So we run through Billions of these different shocks to see what will be the risk through this what will be the pricing in this different scenarios Finally, we want identical pricing across all our offices like front office middle office back office and Irrespective of location and minimum time to market. So there are two pieces To the magic that is happening here. One is the client side So the client side enables us to have good what if analysis Where let's say we developed our own development environment Which enables to have a graph like environment? So if I have formula C equals a plus B, it will automatically make a day-to-day cycle graph and The calculations can happen it enables memorization So many of the results can be reused and the time to market is enabled by our SDLC where Feek few click buttons and your system or your code is in production so the for the rest of the topic will be Focusing on the other piece which is the persistence layer and what we have done there and what is the evolution there so this is We came up with a very simple back-end design, which is a in-memory blob store essentially, right? So there is a shared memory it has parallel readers and serialized writes So there are components to rights, which is checker logger and applyer. These can be pipelined To kind of increase some of the throughput But essentially the the blob store under science two kinds of objects one which is a Blob which is has a metadata which has some essential information about the object, which is what class it is and What are the Essentially what are the what is the type and what is the name so so the all the objects are stored have indexes on name and type and There is a variable size binary Apart from that there is a special object that the server understand which is called a position So that's a specific name for enabling our trade model, but A position is essentially a conflict-free data type Right, so it is implemented as an incremental and in the next slide. I'll kind of focus more on What is a trade model? so Now one of the key features of our persistence is that like because of the simplicity like there are Like five people in the SRE team who manage a deployment of more than 10,000 physical kind of instances of this system now We need to enable real-time risk at all locations We need real-time synchronization of data and it's a multi master right environment where Traders in any of the locations can be updating the objects now we try to kind of design a system which Reduces conflict so it's an eventually consistent system However, our trade model is designed in such a way that there are minimal conflicts to enable that we have For each of the physical instances the trade ID range is unique. So the trade ID is don't overlap in different locations The traders are trading in objects that are called tradibles. So these tradibles are either singletons or Fungibles so when I say singletons for example a house in San Diego will be a singleton So there is only kind of a specific type of house in San Diego Something like oil will be fungible which adds up like our oil from Saudi Arabia or from Canada They kind of add up right so You can trade these either countries of one or these things add up so trades or transactions which are happening Create positions on an account which are unique and these positions as I said are incremental on the back end so even though The traders might be acting on the same account which are kind of The conflicts don't happen in general If conflicts do happen we have a conflict resolution tool that kind of solves the conflicts So to give some again, there are few impressive numbers on the first slide But now this is supporting like so so so the In memory database or and kind of no sequel was kind of ahead of its time But the key completely advantage for us was that this was uniformly adopted across the entire firm What that means is Across hundred different business units. This is a single entry point for all the trades and all the risk so through kind of Why this is a competitive edge because For example when financial crisis happened And I like I was on the trading floor It was a single query for me to figure out what is our exposure to different counterparties and this was very kind of Very very powerful Secondly, we use the same persistence to distribute our code as well right, so Everyone has the same view of the world at all points of time So what is usd versus euro is the same price that anyone is seeing like nobody's checking out code checking out code and Kind of doing pricing separately So these are kind of very powerful features here Now what is in the future So basically as I mentioned financial crisis post that that was an important year because post that the nature of the industry itself changed and So for example a lot of derivative or proprietary trading Became obsolete and there were more algorithmic trading So over time there were more kind of engineers than traders and bankers So we are at a point where we have more engineers and Secondly the the the technology itself matured also so where we were using our own language which had both functional features and imperative features now we have Model languages with support both as well as on the persistent side We have mature no sequel offering so apart from The businesses themselves are becoming more and more data-driven right so Many of the models that we rely on can be derived from data So we want to build this platform for future. Although this is still kind of very very profitable for us We want to Desiree design the system for future and there are few important considerations that we have and These decisions are more directional than technical which is we can again rewrite a proprietary system We have good C plus developers who can do that but As we are as we look at the modern generation they are more enthused by open source platforms and Like having those skills which which can be reused So that's a very important decision for us that a boutique solution that we have built which is highly optimized for us a single kind of system supports all kinds of use cases be it high throughput trading be it archives be it ticking data it solves everything To go to a open-source solution Which is more generic in nature. It's a very big engine challenge for us to kind of match the requirements So a we want to use open source and be we don't want to Make the observed performance of existing system any worse. So when we kind of So in phase one, we don't want to change any of the clients, but as we change the back end We don't want clients to face any kind of performance degradation and that's where all the engineering challenge comes up so How how we are doing that for that? I'll invite Richard Maheshwari Like words are being journey so far. So essentially We are trying to solve Two problems here. So one is we want to replace our key value store That will make the system as is compliant to our existing system and secondly because a blob store is not amenable to Like server site queries the clients need to civilize the data on this site and then make queries We want to also solve the olap problem here. So we have apart from solving the OLTP solution We have a real-time sync to make the blobs into attributes and then Move the query load to this attribute store Right. So so that's how we are kind of thinking about the new system and Russia will take you through the journey How we are going there? Hi everyone, okay, so let me take you through the journey of how we started with foundation DB and What are the steps we took and where we are right now? So as I look told that we already have a proprietary system with us Which is basically we have clients we have the back end which is essentially a blob store And we have a well-defined protocol and the first thing which we wanted was that we wanted an as is Replacement of the back end without any change in clients Which means that what we started with is that as is replacement of the blob store Which means that we first defined a middle where so we first defined a unit Which is between the foundation DB blob store and the clients and we supported the same protocol as is Which is currently a sick DB. So the first step was that a middle where which has which has Which has discoverable endpoints with the same protocol as is and also the first offering which we gave was that basic credit operations which will insert the blob and Retrieve the blood for the client apart from that the second point is that In sec DB rather apart from being a simple or document store It's also has some limited indexing support So when I say limited indexing support if you are familiar with record layer or Document layer indexing. It's very similar to it. Which means that a client So schema here is managed on the client side Which means that when a client wants to store a document it will serialize a document as a blob store and store it in the foundation DB and if a client wants to fetch the document it will get the blob deserlize it from the clients client-side manage schema and get it The indexing support is something like we can register what fee of what attributes of an object or a or a security are Indexed and what happens is that client knows that these attributes are index So the client sends the blob with the indexed values and registered in a particular format and If other clients wants to query those indexes they can basically Start with an offset and iterate through the indexes It's very similar to how record layer and document layer do it And then that with the as is replacement So this is these are the as is replacement for the client for the users for our DevOps team We our current system already has tools like backup restore and other systems and other tools We tried to replace all these features as is For them as well. So these are some of the features which foundation DB supports out of the box So they were all supported as is Other than that one of the things which I look mentioned was that Apart from the simple limited support which we have that is blob store and indexing our clients also wanted the support of rich server-side queries which means that if we index something or we We provide attributes to the server that we should have ability to support rich server-side queries like aggregation or Composite indexes etc. And that's where we found it record layer very helpful and that's where we are using it So what we did was we encode the Attributes in portable format store it and based on using record layer or record layer principles we tried to have these queries and Also, the other thing is that next we looked at the the other requirements of clients for example one of the main requirements of clients is that they want to Measure risk as of a particular milestone So what was the risk if this condition was valid or what was the risk as of some particular time? And we wanted some milestone milestone based on which we can query data and The roadmap of foundation DB looks exactly To what our future roadmap is which is there's there's a roadmap for Edward engine which will provide that Milestoning layer So that is what it is So this is a journey where we try to do as is replacement of foundation DB with our system And this is where it fits fits our bill foundation to be exactly as is But there are a lot of places where it there are few places where it doesn't fit the bill and for that I will I will invite a subwoo. Hi. Hello everyone. So I'm gonna talk a little bit about the next steps, which means We are not in production yet So we have done a lot of analysis and this is more about the what we need to do before we actually go to production So being a financial firm I mean the need all of the kind of the DevOps requirement on the security requirements are pretty high for us and Also the environment what we operate is a little bit different So because we actually have a thick clients who directly interact with the native blob store Which means we don't really there isn't like a strict need for a layer in the middle for the read operations So we have these hundreds of thousands of clients running on one side And you have a server on the other side which we think will be foundation DB And they want to natively read the data and do something on that side. So that Brings in a lot of interesting propositions like what about a DDoS when we natively expose this cluster to these hundreds of thousands of Clients can all of them had the hit the cluster at one go and bring down the cluster and can they work on the Infrastructure so how do we manage something like that and then comes the sum of the regulatory and the audit kind of requirements Like for us we have to record every single meaningful thing that happens in a production system Which means if somebody is like adding a machine to a cluster or taking a machine out of the cluster We actually have to record everything. So how how do we do that and then we have things like Purely the security the authentication. So who made a transaction? How do we identify what a client is? So while foundation DB as well as this acid blob store ticked all the boxes And then we realized we can't really expose it we can't really run foundation to be natively as a service for the clients directly and That is where we are and we need to build a layer to like a DevOps layer to and a security layer to secure a lot of these operations And the next part is performance. So as I said, we have a thick clients and sometimes even a desktop-based clients running on one side that kind of means the The the concurrent connection requirement is like a hundred thousand requirement. So it Currently we kind of scale but foundation to be is not built for that So we still think the layer will actually help us Scaled for that and we have other things like the fast Restoring backup that is a very very key requirement for us because at the moment It is a complete in-memory system in 10 minutes We can actually have a clone of a database running the size is small But the the bar is pretty high because it's quite literally takes 10 minutes for us to If we have a database running in New York and we won't have a copy of that running in London It takes 10 minutes for us to copy the data over and start another instance. So that is another one and It's kind of path ahead as I said We plan to write this DevOps layer which we think is genetic will be useful for the rest of the community And we want to build it and we want to give it back to the community That is one part and also help with some of the capacity requirements and in terms of the collaboration as I said We want to Write this layer in a generic way so that you know, it can be used by other people So who likes him reviews and feedbacks from you guys and then the ass of requirement is a very very key and a very interesting Requirement it is it is sort of a game changer for what we have in the current system So whenever the Redwood engine comes we are really looking forward to it will help you with testing and also adoption Quickly give to your luck for the closing remarks Yeah, so I think Like segdibi has been kind of doubted as the secret sauce of Wall Street. So this is the first Year when we are talking about it In international conferences So this is a very big kind of milestone from our side and our collaboration with foundation DB has been very good So far so looking forward to the journey. Thank you