Rakesh Sagar

So about me, it's, uh, about me, it's like, uh, sorry. I, again, went back. For instance, when you had a leverage book. So I was. Yeah. So I recently went through this. So what we do in our project is we basically have emails. We we process emails, and the emails basically has subjects. And, uh, if you are doing any online purchase, we have items, and then we have, like, totals that we that is given to us for which we paid pay the bills. So when we what we do is process the email files and extract data out of it. So the email files that we were receiving had, like, a lot of metadata or bad data, basically, we could say, with the subjects. And we, like, identify our, uh, files through the subjects only. So in order to remove the in order to clean up the subjects, we had to I had to make a make an application which involve both, uh, Python and Java. So through Python, I was, like, downloading all the files or I won't say downloading. I was, like, copying all of data from the production to my local, and then I would run a utility which would, like and that's that utility would be was built on Java. So that utility would clean up the email files or the subject. And then once the subject is cleaned up, we had to, like, group it group the subjects together, its counts, and the dates dates in which it was received and all. And once that was done, means, like, a 1000000 records could be a 1000000 emails could be reduced to a group of, like, 10 subjects or 20 subjects like that. So I built a utility of that kind. Yeah.

So to start with, as for single responsibility, basically we have to, whatever we are doing, like if we are making an application, which is like, let's say an e-commerce application, so e-commerce will have different participants in that and like, let's say a participant is a customer, a participant is a delivery boy, a participant is a restaurant. So one particular set or should only represent one particular participant. So if I am making a class, which is for ordering food or ordering, let's say anything, like let's say I'm ordering a keyboard, so it should have only order related data and when it comes to payment, a payment class should have only payment related information, both should not be mixed. So that would be our single responsibility and O for open close means we should be open for extension, closed for modification. So if I want to like add some more details to the order, I should be able to like add it through some other means and I should not be modifying what already exists and what's already working. So it should be written in such a way that it could be extended and let's call substitution principle basically. So if we do coding to interface, do write code in the way of coding to interfaces basically. So if we are writing something like let's say car and it's a car is an interface and it is implemented by say an auto. So we should be able to put an auto into a car and we should also be able to put a polo inside a car and that the things below it, which is like extending it or whatever is written to support should not be should not break. I was in person. So basically this, this is where for I, I forgot the extension or the abbreviation, but this is basically is to like when we are making an object for a something that is going to be used in my current class, we should not be passing or we should not be making the new object itself. So it should be passed as a parameter means so that it is like the two objects or two classes remain independent of each other. So it is basically inversion of control thing that we use in use in spring. I forgot the abbreviation and D is for, is for D is for dependency injection. Okay D is for dependency injection. The first one that I said means before the statement that I just read before these for dependency injection and we pass an object as parameter to another object, not directly make a new object.

I am not sure on this I have not worked on the AI models yet so as far as the micro services itself are concerned we could have like micro services in different languages and that could work together so all I can think of over here is inside a Java micro service we can call another micro service through a URL and that could do things we want to do but AI models itself is not a familiar ground to me as of now.

so first up of course an introduction of a new microservices should not disturb the existing ecosystem so basically it should run independent of the existing ecosystem and should be a complete entity in itself and could should be deployed in a separate server which could like start communicating with the existing ecosystem through URLs and yeah for the existing system whatever communication happens we should have a like failsafe design so if the if the API call is not successful then it shouldn't break the system or other API should not get affected with it so when we are introducing a new one basically it should be as non-existent to the existing ecosystem as if it was never present so the considerations what I can consider over here the so basically I should just be aware of what API's are being exposed by the existing system which I can use in my new new microservice that I am going to introduce and I should be having the documentation of the existing ecosystem API's means how it can be used and what things need to be passed to access the microservices in the existing ecosystem basically it's documentation I can think of that only

Then should you opt for monolith architecture or micros is personally concerning Java and Springboard application So I Should consider a monolith over micro service if my maintenance means there are several things over here that Needs to be considered So the first one would be I would say it of course would be the size of the application and Means that as the size of the application increases it basically becomes hard to maintain and it becomes tough to like deploy or maintain the application itself, so Yeah So if the first point would be to consider monolith over microservice is if my application is small enough to be like deployed and Like The damage on stopping the service should be minimal Then yes monolith is fine Like we do in our current project The Second could be the Rk the cost related to microservices means So if we are using micro services architecture Then we probably are going to think of the infrastructure where we wherein we will be like using multiple servers to and Then there will be like different infrastructure involved in maintaining those micro services or like Monitoring those micro services. So those things come at a cost then there will be like the downtime could be minimal, but then the maintenance means Maintaining the logs or just going through the logs itself if something goes wrong becomes a little more challenging than what we can have in monolith where it could be like straightforward and What else You What else I can do over here for monolith, why should I choose monolith? You When it comes to the development or like creation of the deployment Is basically as As a coder I would say that it becomes much easier for the developer himself so because he won't have to go here and there and he won't have to like Think of ways to like Basically thinking of different ways to for the downtime to be minimal or for the failure to be I'm not really sure means what else I can think of as of now You

Examine the java code that is in need to lazily initialize an instance of service Can you explain what is wrong with this code and how what could happen if multiple transactions get service instance methods simultaneously? Private static service service public static service gets service instance if service instance equal to equal to nulls Then new service returns service instance service Instance of a service So what's happening here is it's not synchronized It's not thread safe So it could happen that a thread accesses the service factory and goes to the line private static service service instance and then it doesn't Reach the next line the next threads accesses the class And then it also sees the service instance as null then goes on to initialize the service and then It doesn't return and then it basically Goes back to the first thread So first thread means now the service instance has been initialized and it's a static variable so The second thread will also So The second thread has its service instance still as null It will go inside and then it will try to initialize. So the service instance has been initialized by Twice And now There could be a conflict over here means since it is static so Basically there will be two instances which has not The way we are looking at we don't want to initialize The service instance twice. So this public static service get service instance method This needs to be synchronized this needs to be made thread safe

Given the java snippet below, can you identify the problem with the singleton design pattern implemented here and suggest how it could lead to issues in the multi-threaded environment? Okay, private static singleton instance for get instance. So it's again, I'm looking at the same problem as it was in the previous one. So since get instance method is not synchronized, it is not thread safe. So there could be like two threads coming in. One comes till the private constructor or private singleton line and then the control could go to the next thread and then it will come and we'll see that instance is not initialized. It will go inside the method, get instance, it will try to initialize and then the control, it will initialize the instance and then the control may go back to the first thread and then the first thread will also initialize the instance with new singleton. So instance will be initialized twice, which we are trying to avoid and so we should make it thread safe so that once it has been initialized, once the instance variable has been initialized, it doesn't need to be initialized again, no matter how many threads try to access this, it should get, all the threads should get the same instance of the singleton class.

So when we are talking about the microservices ecosystem and then there are multiple data stores as well, backup strategy for a microservice ecosystem that spans multiple data stores. So having worked on the data protection ecosystem for five years, I could like think of the easiest way is to like backup each server where every microservice has been deployed and there are multiple data stores, each data store will have its own backup. So as soon as, whenever a microservices goes down, it can have like a backup means each microservice needs to be deployed in like different servers. Like it depends on the size of the application, the might of the service provider itself means the might of the owner of the application, how much money he has got means how many servers he can access or how much he can spend. So we can have like multiple servers for one microservice and then even for backup we can have like, we can have each server backed up in different places. Like maybe as I had worked in a, in an organization where all the data were like was backed up in at least two places in different geographies so that even if some disaster happens in one place, all the data could be restored. So yeah, first up means just to make sure that the application doesn't go down, we should have a microservice, every microservice in the ecosystem running on multiple servers. So like if we have 10 microservices in the ecosystem, we should have like, maybe we can have 40 servers running, four for each microservice and the data stores wherever, like whatever data stores we have, we could have the backup of the data store itself running parallelly to it. And if one server fails, one server fails in the, for the data, the others could be used as a backup immediately. And apart from that, the data store itself, the server itself could be like backed up in different place where, which is not meant for running the application, it's just meant for a backup. So as a, as a server goes down, we replace it with a new server and then we like copy all the data from that particular backup and then we are back in business. So yeah, is there, there are different ways, a lot of different ways which we can think of, but these are a few things we can think of, yeah.