 Welcome back to CouchBaseConnect. My name is Dave Vellante. We're going to dig into a customer case study of sorts with two software engineers from a company called Trendyall, the largest e-commerce platform in Turkey. And with me are Fatih Yilmaz and Emre Tanreverdi, both software engineers at Trendyall. Welcome. Good to see you guys. Hello. Hello. Hey, before we get into the story, maybe you can tell us a little bit about Trendyall. Let me answer that question first. Trendyall today is 10 years old, actually. It starts with an e-commerce company, especially for clothing. Today, it serves several services, mainly still e-commerce. We do our business mainly on technology, and we even have a saying technology is our main concern, actually, just like that action for now. So thank you for that. I mean, you started, I think, I think the company was founded in 2009, 2010. So you were just kind of, which we would consider sort of the modern era at the same time when you look back 10 years, you know, major challenges, major advancements from a technology standpoint. So you, at the time you had a legacy database and you had to migrate, maybe you could describe the business conditions that drove you to think about actually making a change. What was the before, and then we can get into the after, and what was driving that change? Maybe I could start a bit. Well, we have a recommendation domain in Trendyall. It's like when you look at a certain product, like for example, you look at a pencil, it's recommending you an eraser. If you are going to buy a pink dress, it's going to recommend you a yellow dress. So if you are going to maybe buy pants, it will show you some t-shirts according to it. So since the recommendations domain grew larger, we have struggled to keep it high scale. And it wasn't a relational DB at first, but as product count increased and our right frequency increased day by day, and our read performance was affected very dramatically. I believe, yeah. So you were using a traditional RDBMS, and the issue was, you couldn't make the recommendations fast enough, and we always say, what's real time? Real time is before you lose the customer. So you have to make those recommendations in time for the customer to act. Otherwise, what do you do? Send an email after the fact, hey, you bought this, and nobody's going to pay attention to that, right? You want to catch them in the moment. And so what was it that led you to couch base? And what was the experience of that? Whether it was onboarding, the technology, how difficult was it to get up and running to where you are today? We were using couch base in Trandall for several years, and we had experience on that, and actually we need performance as Emre described. So we convert our data structure from relational DB to non-SQL DB. Actually, on our recommendation platform, the main problem was invalidation process. You know, we are selling things and in seconds they can be sold out and we shouldn't be recommending them anymore. And we are keeping track of this by invalidation process and with relational DB, writing those data to our relational DB was taking too much time and by changing this structure to couch base we see that benefits and it takes so short time actually. Yeah, so sorry, if I can just clarify. What was taking a long time? Updating the actual records so that you could actually inform a customer that it was out of stock or was it the coding that was too complicated? No, it was not the coding. There are millions of products in Trandall and those invalidations are coming huge actually. So we are keeping track of them if it's sold out or it can be sellable. When a product detail is seen by the customer, we are recommending some other products too but those other products must be sellable too. So the main problem was that and we are writing them in our relational DB that there is a huge right load actually. So it was not coding, it was the amount of data actually. Okay, so it was the update intensity within the database and the ability of the database to actually return accurate results quickly. So what was the after like? Can you talk about sort of the business impact? What were the improvements that you experienced? Yeah, maybe I can answer that. Like Fati said, the main reason we switched is because that there are so many products coming new in Trandall and many of them are being sold out and the updates to it was on our relational DB and the rights were too much that you couldn't give our customers a fast reply because the database was getting affected by the amount of high rights because when you think about it, there are millions of products coming and there are millions of rights operations on the database so it was affecting the read performance. So it could occur to you that when you click on a product you would see maybe a stock out product as a recommendation or maybe a product that is not in the website anymore. So when we switched to a couch base that we saw that it's using less resource with using less pods active alive and it's also giving responses faster. The main reason we were using relational DB at first was the invalidation process like Fati said because we had a consumer that was listening to messages, the invalidation messages and then writing them into database. But in the couch base part, it meant that actively writing to database that for every product document that you would need to update the document but for relational DB it would be we thought easier to just make this product available false or true. So that's why we were sticking with relational DB at first and that's why we made it at first as a relational DB but as time increased and our product count and our sellers increased, we realized that we should find another solution to the invalidation process and we should switch because I mean it had come to a point that it would just maybe take so much time that we were scaling our consumers at night time to just not affect daily users anymore. So that's the main reason we switched and after switching, we had improvements in like I said, response time and high write throughput and also one of the reasons is also because that the replication abilities of couch base because since trend is growing larger there are many data centers and like we can see that every day sometimes we deploy our apps to get another cluster and that's why we sometimes need to have backups or different data centers and the couch base was providing very good relation very good solutions to this with this XDTR. Yeah, that's why we switched actually to the ends. So is couch base running, if I understand it it's running the recommendation engine and do you still use a traditional RDBMS for the transaction system or is couch base doing both? Yeah, you're right, you had better add. So sorry, you could go. Okay, we are actually in Trandall, we are in Discovery team actually, we call it TRIVE and in Discovery TRIVE relational DB I think now very small small teams are using it. Its percentage is very low actually but other tribes, for example, orders, checkouts maybe promotions, something like other teams are still using RDBMS but in Discovery team it's very important to serve customers very fast. We need to show them products immediately we need to personalize them we should show them related products in real time actually. So in Discovery TRIVE we are barely using it, RDBMS systems actually. How hard was it to migrate from the RDBMS because you hear a lot of stories about how difficult that is to do you've got to freeze the code you're bringing up new code you've got to synchronize the functionality how did you manage that? Well, to be honest, we just asked the data science team to just send the products at the same time we were keeping the legacy API open that the clients were still coming there and to be honest, there were lots of lags on that too. So even if the newer products came a bit later it shouldn't be seen because it was already coming late. So we made a new API that is connecting to Couchface and we wanted the data science team to start feeding it but we asked the clients to switch it by time I mean, we were still supporting the old one but when we asked the clients to switch to the new API we just closed the last one so we didn't really migrate any data to be honest like it was from scratch and since it's a recommendation domain we believe it's better to add data from scratch because in our new domains if you are storing them in documents they are always sending a new list to us so that's how it gets updated all the time. So since it's not a user-related data it wasn't really like a migration process. Is this part of the secret sauce that you're doing schema-less, no schema on write to Couchface and is that correct and how are you handling it? How are you getting that awesome write performance? Well, the main reason we believe is that before when it was relational DB like for example, one product to one product and second product to first product third product to first product like you were duplicating the records so that when the product gets removed from a product's recommendation or maybe if a product is getting invisible for any reason it should be removed or maybe it could be a stock out that it meant that for every record you are sending a record for invalidation but in our new system it means that for this content there are 24 contents, let's say and like four of them got finished. It's okay, you are just replacing the whole list so that you are not duplicating the records. I mean, it's not like first product to first and first to second and first to third and if first changes you are duplicating this change three times like delete product one from three delete product one from two. You are duplicating the deletion record but now you are just replacing the list. So you are doing that all of the operation in one Kafka queue message if I was able to tell about it. So it's a bit hard to explain it in speech but we have a nice graphic that's showing how we are doing it now. That makes sense, okay, thank you for that. And so as you think about your modernizing your application infrastructure where are you at today? How do you see this modernization effort going forward? Actually, today we are mainly looking for cross cluster replication. All our products are deployed different clusters and different geographical locations. We always using, we try to always use modern products and try to avoid old relational databases especially for our discovery tribe and by modernizing it our engineers keeping up to date with recent technologies and our customers are happier. They're not seeing some glitches, some weights while they're using our products. Okay, so maybe I could double click on that because you mentioned the impact of customers and I'm interested in your organizational impact and what means for you internally but when you talk about cross cluster replication is that to scale, is that a performance impact? Is that for availability? What's the impact of that effort, that modernization effort? I believe it's all, the main reason is availability, I believe. Like we can't know when a cluster can go down. We can't be sure about it in any system we can but that trend should be up and running all the time and there should be some backups that can switch when a cluster goes down but also the main reason, one of the main reasons is to be able to scale because the clusters that we had wasn't enough considering our user base. So let's say you want to even extend your user base but the cluster is being a bottleneck to you because you can't get that much users but when you do cross cluster that you have backup and you have scalability and it's considering if the machines are newer maybe faster response times, I don't know, maybe network part would know that better but yeah, all of them, I believe. Great guys, well thank you so much for sharing your story, Emre and Fatih. Appreciate you guys coming on theCUBE. Thanks a lot, yeah, thanks, thank you for hosting us. Yeah, it's our pleasure and thank you for watching CouchBase Connect Online on theCUBE, keep it right there for more great content from the event.