 Yeah, hello everyone. I'm Rohan Prabhu. I'm the founder at CommandK.dev. I came across this amazing talk by Rukindran Pratap about how to take data anonymization over at LinkedIn. To give a bit of background about me, I was director of engineering over at Jupiter, which was one of India's first Neobanks. And then, you know, being in the FinTech space and in the Neobanks space, of course, this is one of those aspects, data privacy, user data protection and anonymization. That is very, very close to our heart. Of course, from the perspective of regulation and compliance and what is simply required for us to be in business, but also simply, you know, when you're dealing with people's money, you have a commitment and you've got to live up to that commitment that you're always going to protect your data and privacy. And some of those efforts at Jupiter were led there by me. So it has been gracious enough to invite me over for a reaction due to LinkedIn's version of the data anonymization layer and privacy protection layer. So just a couple of thoughts from my side. First of all, like a great shout out to Rukindran Pratap for an amazing deep dive into the architecture over at LinkedIn. And of course, you know, LinkedIn is a company, the scale at which it is that just makes this challenge 10 times more impressive for them to have solved it or you will take a crack at it. At the very outset, basically, you know, the success of LinkedIn's implementation lies in the fact that they have figured out the central points where data is either ingested or processed or data is read from. And those are the places where, you know, you have these primitives of read and write or maybe even higher level primitives of data transformation, which kind of allows them to centralize the control of, you know, anonymization, whether you want to do anonymization at read time or at write time as well. In that aspect for all companies who are committed to this and even regulation is going to just get more and more stringent about it. Well, look at this as you know, platformization I think is the big bet, you know, because platform services are a lot more aware of the underlying data scheme structure, the lineage of data. And so the central platform piece is, you know, much better for us to be able to detect where data goes and how it is used. And then undeniable sacrifice and looking that they are able to build other abstractions which might sometimes be higher level, like the ones we saw in Delhi, which they've written and the centralization. You know, having simple primitives of read write allows them to build scalable privacy and compliance operations. And when I say scalable, I'm not just talking about scalable in terms of RPS, right? But it's practices that grow even when you're running 20, 30 services every year, you're probably running 50 engineers a year. And you know, you're writing port at like a rapid, rapid pace. And across all of this, you're still maintaining all of your operations around privacy, anonymization, some cases even localization, and then that's still scalable. So it's really an impressive extent to see the extent to which the user data has grown. It was the challenge on your line storage is like even more crazy. So then the lookup table implementation is what's kind of really, it's very innovative. The fact that, you know, you just do the data has to be scrubbed out or data that has to be anonymized. You keep some reference to it at any point of read write or transform to have like this perfect places where you can use the LUT to kind of figure out whether you want to do like a like an offline purge or a data purge or anonymize it. By a large, one aspect that really stands out on the statement back to the time and we implemented the PI Reductions system at Jupiter. And I think this really holds the key to a successful compliance strategy and not just compliance, right? Again, as I said, it's also your commitment to protecting your users' data. Then applications continue being built the way they always have, right? Towards towards the end, they have this comment on, you know, a database is a database and rows and columns are rows and columns. And all efforts to protect user data are all essentially centralized, right? So because what happens now is A, it allows the right decisions to be made at a central level. It allows for enough flexibility as advancements and complaints that are made as more regulations come in. People figure out smarter ways to build more safeguards for their users. And the most interesting thing, the most important thing is that you're still allowing the exact same velocity and pace for engineering. But efforts around data protection are not perceived as important. So that helps keep your organization's commitment much more active because people are not expert in making decisions. They're not. Software engineers have graded writing code and they continue to write it at the same pace. You're releasing features, you're releasing your services out at the exact same pace. And it's a cross-cutting concern, right? So the compliance is a cross-cutting concern and it should be seen that way. And I think the architecture of LinkedIn of this is just fantastic. And it's a testament of, you know, how you really invite the concept of implementing cross-cutting functions by having a very, very strong platform layer. And I think that's the key insight for me from the site. And I think that would in general be the advice for any companies looking at going down the compliance tech route as well. Thank you.