Puneet Bhadauriya

So myself, Puneet, and I have I'm a software engineer working in the IT industry for the last twelve years. And, primarily, I have been working with the Microsoft tech stack. There, I have basically worked on many technical things. Like, starting from my career, I have worked on wind farms and the WPA. After that, I got a chance to work on mobile development using Jaming, which is a crash platform framework. And after that, I have been working on API development where I was mainly part of building or building the API, which can scale to millions of users, and we can support that load. Apart from that, also, I am part of the architecting team. So I and my team have rearchitected couple of modules in our product line so that we can support multiple other customers, which are not in the same data model or you can say, they are huge in those dimensions. So, to support them, we have to re architect some of our modules. I also migrated my dot net projects, which were running in Windows only, and then we were not able to use them on Linux or Kubernetes. So I migrated all my media kind products to dot net core. And since then, we are in the cloud world. Also, last three years, I am working as a senior tech lead. There, I am playing three roles. One is, mainly, I'm doing development. But on the other side, I'm part of requirement analysis and gathering, and then seeing whether they are good to be put in the product line or there is some architectural change. There is team collaboration as well in the same time, and then my team is there where we are doing grooming and we are delivering those features. And, I'm part of performance testing and, you say, whenever there is some issue is happening on the production environments, I'm the one who is the subject matter expert. So I also play a crucial role in those calls where I can try to mitigate or resolve those problems. So that's pretty much me. And apart from that, I'm also a good learner and keep adapting to anything. So last one year also, I am supporting one of my Java project, which has come as a transition to me. So I and couple of other people in my team were supporting that. So, usually, we were able to deliver three to four features within six months. And so, yeah, Java is something I am also comfortable with, not proficient, but comfortable. And then apart from that, I am very comfortable with front-end development where I can build something using Angular or React. And then I can integrate APIs and all in those modules. So, yeah, pretty much, yeah, I'm comfortable with this.

So at your service, we are not using our product line. We are using Kafka to paste, but they are pretty much the same. I can relate how your service bus is basically working. The idea is basically when earlier, we had a monolithic architecture where one service was deployed and all the load was coming to that service only. And scalability was a problem with that type of architecture because you cannot scale horizontally those services. It can scale up to vertically, and then there is a limit to RAM and hard disk. And that is where these microservices or decoupled components came into the picture. And to basically communicate with each other, they'll need some asynchronous mechanism. So that is where Azure service bus plays a crucial role, which can basically play as a publisher and subscriber. So when an event is published in an asynchronous manner, that can be basically listened to by other dependent microservices, and they can perform some business. Right. So yeah. Topics are basically where the messages go. Messages are basically put there. And from there, subscribers are basically consumers or someone who consumes those topics. So first, they subscribe to those topics, and then whatever message is coming to those topics, they can get consumed. We are using Polly for retries. It can be used because you shouldn't unnecessarily call your API, and the services won't respond. You're down. So that is where this retry mechanism or circuit-breaking strategies came into the picture. We can use Polly, which is in the.NET library, and can be used for retrying. There are on/off toggles, which can be used to specify how many times you want to hit that. If any after that, you can do a circuit-breaking and be ideal so that your breaking service doesn't get impacted with the other service, which is not responding. You're basically breaking down. Apart from that, yeah. Okay. Yeah. So pretty much, yeah. I have covered this question, and yeah. So, reliable communication between microservices or decoupled components can be done using these Kafka, Redis, or Azure service bus because they are basically writing messages on the topic, and then the topic is subscribed to consumers, and consumers are continuously getting those messages, and they can play. It's more so-called as event-driven architecture in the microservices world.

I don't have much exposure to Azure functions, so I will not be able to answer this. And I'll skip this for now, but this is something which after Java, I will be learning. I have written couple of Azure functions just for practice, to understand how they work and how we can use them in a sample project. But in our product line, we weren't using it initially, so I won't be able to answer this question.

So dependency injection is a design pattern used in modern applications to keep two dependent classes independent. Let's say there is a dependency in terms of a class object which has to be available in the second class when we are creating the object of it. This can be resolved using dependency injection. One way to do this is to manually create that dependency and pass it to that class, and the other way is to use inversion of control frameworks, which can resolve dependencies at runtime based on the requirements of your component or classes. In.NET Core, there is an inbuilt dependency framework that we can use. However, in our.NET framework application, we also developed a custom dependency module that we migrated to.NET Core after the migration. We are not using the inbuilt framework from.NET Core, but it's doing the same thing - we can inject our dependencies, which can be either transient or singleton. Services are re-registered using service configuration. You can use AddScope, for example, to specify transient or singleton. And when you're lifting that dependency, it will be resolved via the framework. So, we'll have a default object of that class, which you have injected into the class. That's how it's specifically done.

Not too much idea about Azure Event Grid, but, the basic concept is very similar. Whatever messaging services are available, be it Kafka, be it Azure Service Bus or Amazon SQS. Events are all the same, basically. So you publish a message to a topic, and there are subscribers or consumers that have subscribed to those topics, and they will be getting those messages. Okay. And so we are using it in our image basically, in our application, which is a media-oriented, I mean, media-driven product line. So what happens when we are getting schedules or whatever, whenever we are getting any images as part of the GIF images in our product line. The idea is basically to improve, increase, and do that work on more machines. We are using Kafka and the publish-subscribe pattern in our image processing module, where whenever there is an image to be processed, we are keeping it in a topic, and then there are the consumers who are getting the message to process. And then we are performing image resize. Same is true for our scheduled processing where we are getting hundred thousand schedules in a GIF, and the idea is to basically split this to parallel machines. We are using the publisher-subscribe pattern again where we are keeping those schedules in topics, and then there are consumers who are getting those schedules to be processed. So that is how the work which we are supposed to do in, let's say, two hours, for example, we are able to do in twenty to twenty-five minutes just by splitting that work in multiple machines. So this is one part where we are using this. And then our microservices for communication, we are using the publish-subscribe pattern again. So yeah.