>>Welcome back to Couchbase connect. My name is Dave Vellante and we're going to dig into a customer case study of sorts with two software engineers from a company called trendy all the largest e-commerce platform in Turkey. And with me are in MRA, tan Rivera, both software engineers at trendy. All welcome. Good to see you guys. Hey, before we get into the story, maybe you can tell us a little bit about trendy all. >>Let me answer that question first. Um, tri-annual uh, today is, um, 10 years old. Uh, actually, uh, it starts with them, um, e-commerce company, uh, Jen, uh, especially, uh, for clothing, uh, today, uh, it's serves several, uh, services, uh, mainly still e-commerce right. Um, we, uh, we do our business mainly on technology and we even have a say in technology, uh, technology is our main concern actually. Um, just like that actually now, >>So thank you for that. I mean, you started, I think, I think the company was founded in 2009, 2010. So you weren't, you were just, you know, kind of which we would consider the, 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, at the time you had a, uh, a legacy database and you, you had a migraine, 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? >>Um, maybe I could start it a bit. Well, uh, we have a recommendation domain and try new. It's like when you, when you look at a certain product, like for example, you look at a pencil, it it's commanding you, uh, any razor, uh, if you are going to buy a pink dress, it's going to recommend you a yellow dress. So if you're going to maybe buy pants, it will show you some t-shirts according to it. So, uh, since the recommendations, domain group larger, uh, we, we have struggled, uh, to keep it high scale, and it wasn't a relational DB at first, but that's even as product count increased and, uh, our right frequency increased day by day, uh, and our reef performance was affected very dramatically. Uh, I believe. Yeah. >>So you were using a traditional RDBMS, uh, and then, and, and the issue was you quite, you couldn't make the recommendations fast enough. And, you know, we always say what's real time. Real time is before you lose the customer. So you, you have to make those recommendations in time for the customer to act otherwise, you know, what do you do? Send an email after the fact, Hey, you bought this, nobody's going to pay attention to that. Right? You want to catch them in the moment. Um, and so, so what was it that, that led you to, to Couchbase and w and what was the experience of that? You know, whether it was onboarding, you know, the technology, you know, how difficult was it to get up and running to where you are today? >>Um, we were using ch Couchbase in, uh, in inter-annual, um, for several years, and we had experienced on that. Uh, and, uh, we actually, we need performance as described. So, uh, we convert our data structure to, from relational DB to, um, noise, Carol Levy, um, them actually on our recommendation, uh, platform, the main problem was, uh, invalidation process. You know, um, we are selling things and, um, in seconds they can be sold out and we, we shouldn't be recommend them anymore. And we are, we are keeping track of this by invalidation process and relational DB writing those data to our relationship Libby was, uh, was taking two, two minutes too much time. And, um, by changing this structure to, uh, pathways, we, we, we see that benefits, uh, and it takes so, so, uh, uh, short time, actually, >>I'm so sorry if, if I can just clarify w what was taking a long time, the, the 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? >>Well, it was, it was not because, um, there are millions of products intangible, and, uh, those issues are coming huge, actually. So we are keeping track of time if it's sold out or it's, it can be sellable, uh, when, when a product, uh, detail is seen by the customers, we are recommending some other products too, but those other products must be sellable too. So the main, the main problem was that, and, uh, we are writing them in our relational DB. There is a huge rights law actually. So it was not coding. It was the amount of data actually. >>Okay. And so it was the update intensity, um, within the database and the ability of the database to actually return accurate results quickly. So what was the after, like, uh, can you talk about sort of the, the business impact? What were the, the improvements that you've experienced? >>Yeah. Maybe I can ask her that, uh, like parties said that the main reason we switched is because that, uh, there are so many products coming near in trend, and many of them are being stopped being sold out and the updates to it, it was on a relational, the vendor rights, or too much that you couldn't, uh, dur customers that fast reply because the database was getting effected by the amount of high rights. Because when you think about it, there are millions of products coming, and there are millions of rights, uh, operations on the database. So those affecting the reach performance. So, uh, it, it could occur to you that when you click on a product, you would see maybe as took out product as a recommendation, or maybe a product that is not in the website anymore. So, uh, when we switched to, uh, Couchbase that, uh, we saw that, uh, it's using less resources, which, uh, using less posts, active, alive, and it's also, uh, giving responses faster. >>The main reason, uh, we were using relational DB at first was the invalidation process like five. He said, because it was, we had a consumer that was listening to messages, uh, the innovation messages, and then, uh, and then the writing them into database. But, uh, in the part, uh, it meant that actively writing to database that for every product document that you would need to update the document, but for, uh, for, for, uh, for relational DB, it would be vetoed easier to just make this product, uh, every available, false, or true. So that's why we were sticking with relationship with DB at first. And that's why we made it that first as a relational DB, but as time increased and our product count, and our sellers increased, we realized that, uh, we should find another solution to the invalidation process, and we should, uh, switch because, uh, I mean, it CA it has come to a point at one point that it would just maybe, uh, take a solid, so much time that, uh, we were scaling our consumers at nighttime to just not affect daily users anymore. >>Uh, so that's why that's the main reason we switched. And, uh, after switching, we had in, uh, like I said, the response time and high write throughput, and also one of the reasons is also because that the, uh, the application that was with the use of Couchbase because, uh, since strangled is growing larger than our main data centers. And, uh, like we can see that every day, sometimes we deploy our, uh, apps to yet another cluster. And we, that's why we sometimes need to have backups or different data centers, and Couchbase was providing very good relations, very good solutions to this, which is. Yeah. That's why we switched actually. So we asked >>Couchbase running it's if I understand it, it's running the recommendation engine. And do you still use a traditional RDBMS for the transaction system or is Couchbase doing both? >>Yeah, okay. Uh, we are, uh, actually inter-annual, we are in discovery a team, actually, we call it tribe and in discovery, tribe, uh, relational DB, I think, uh, now, uh, very small, uh, small, uh, teams are using it. Um, it's personally just very low actually. Uh, but, uh, other other tribes, for example, orders, checkout, and maybe, uh, uh, promotions, uh, 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 the products immediately. We need to personalize them. Uh, we sh we should, uh, show them, uh, related products in the meantime, in real time, actually. So in this current Stripe, we are, um, barely using it, uh, 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 bringing up new code, you've got to synchronize the functionality. How did you manage that? >>Well, to be honest with you, just ask the data science team to just send the products. Uh, at the same time, we were like, we were keeping the legacy API open that the clients were still coming there. And, um, to be honest, there were lots of legs on that, too. So even if, uh, the, the newer products came a bit later, uh, it shouldn't be seen because it was always coming late. So, uh, we had, we made a new API that is connecting to Couchbase 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, uh, when we, 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 we, we, it was from scratch. And since it's a, it's a recommendation domain, uh, we believe it's better to, uh, add data's from scratch because in our new domains, we 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 is part of the secret sauce that you're doing. Schema lists, no schema on, right to Couchbase. And is that correct? And how are you handling it? I'm like, how are you getting that awesome write performance? >>Well, the main reason we believe is that, uh, before, when it was relational DB, like for example, loan product to one product and a second product to first product, third product, first of all, that like you were duplicating the records so that when the product gets removed, uh, from, from a product recommendation, or maybe one of, if a product is getting invisible, for any reason, it should be removed, or maybe it could be a stockout that it means it's not that for every record, you are sending your records for invalidation, but in our new system, it means that this, uh, for this content, there are 24 contents let's say, and like four of them that's finished. It's not there. It's okay. You're just replacing the whole list so that you are not duplicating the records. I mean, this is not like first product first and first, the second, and first to third, and first changes you are replicating this, this change three times, like a delete, uh, product one from three, three product, one from two, and you are deprecating the deletion record, but now we are just replacing the list. So you are doing that all of the operation in 1, 1, 1, uh, Kafka queue message. If I should be able, if I was able to, uh, tell about it. So it's a bit hard to explain it in, uh, in speech, but, uh, 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, you're modernizing your application infrastructure, where are you at today? How do you see this modernization effort going forward >>Actually, um, today, uh, we are mainly looking for, um, cross cluster replication. Uh, all our products are, uh, uh, deployed, uh, different clusters and different geographical locations. Uh, we, we always using ch um, we try to always use, um, modern products and, uh, uh, try to avoid, uh, old relational databases, especially for our discovery. Right. And, uh, my mandala is modernizing it, uh, all, uh, engineer's keeping up to date with recent technologies and, uh, our customers are happier. They are not seeing some glitches, some, uh, rates, uh, or while they're using our products. >>Okay. So maybe I could double click on that. So, cause you mentioned the impact of customers and I'm interested in your organizational impact and what it means for you internally, but, but when you talk about cross cluster replication, is that to scale, uh, is that a performance impact? Is that for availability? What's the impact of that effort? That modernization effort? >>Uh, I believe it's, it's all, uh, main reason is availability. I believe. Uh, like we can't know when a cluster can go down, we can't be sure about it, uh, in a, in a system we can, but that we should be up and running all the time. And, uh, there should be some, uh, some backups that, uh, that can switch when a cluster goes down. But also the main reason, uh, well, one of the main reasons is to be able to scale because, uh, the, the clusters that we had wasn't enough, uh, considering our user base. So, uh, let's say you want to even extend your user base, but, uh, like the cluster is being a bottleneck to you because you can't get that much users, but, uh, when you do post cluster that you have backup and you have scalability and it's, uh, considering how new considering if the machines are newer, maybe faster response times. I don't know, uh, maybe, uh, network part would know that better, but, uh, yeah, but all of them, I will leave. >>Great guys. Well, thank you so much for sharing your story, uh, uh, MRA and Fati. Uh, appreciate you guys coming on the cube. >>Thanks a lot. Yeah. Thanks. Thanks. Thank you for, uh, hosting. >>Yeah, it's our pleasure. And thank you for watching. Couchbase connect online on the cube, keep it right there for more great content from the event.