Geetanjali Iyer

Yeah. Sure. So hi. My name is Gita here. I am based out of Pune location. I have, completed my bachelor's computer science, mean, I graduated in the year 2015 since then I've been working. So, approximately, I have 9 years of work experience in this, IT field. And, throughout my career, I have worked for a telecom domain. And, the client for whom I worked was British Telecom.

What strategy would you utilize to implement microservices? Circuit breaker for a fault tolerance. What strategy? Okay. Says what strategy would you utilize in Java to implement a microservices circuit breaker for fault tolerance? Okay. So, uh, circuit breaker design pattern is something, uh, basically, what it does. It is, uh, something that prevents cascading failures. So, like, if in your application there is some failure and if it has some cascading effects, implementing, uh, circuit breaker design pattern in your application is going to prevent, uh, the cascading, uh, effects. Like, now, uh, what strategy will I utilize in Java? So okay. Uh, we do have, uh, some dedicated libraries which is Hystrix. It does provide the core functionality. I mean, uh, circuit breaker functionality in it. So that can be used. So that I can utilize in my application. Uh, apart from that, What I know is the hystrix, which it is providing this particular functionality, it allows you to, uh, monitor the health check of the application, the server health, then, uh, some fallbacks if you have that, you can trigger I mean, that can be triggered using some trigger mechanisms. Uh, and apart from that, uh, you can automatically, uh, transition between states, like closed or open, somewhat of that that sort, uh, like, just to manage the recovery, uh, of the application. So, uh, mainly, uh, monitoring failures is something which we can, uh, apply your, uh, then fallback mechanism. And, uh, one more thing which we can consider while implementing circuit breaker in, uh, Java is the, uh, configuration. Like, we will have to set up some, uh, appropriate configurations, like, the failure thresholds or the retry attempts because retry mechanism is something which we can try in case of failures. And, uh, the timeouts, obviously, like, uh, if you have a designated time out and within that time, if you're not getting the response, that is how you come to know that it's not something is not right. Uh, that is one thing. And then, uh, resiliency libraries, um, we can use. I mean, uh, as I just mentioned, Hystrix being one of them. Uh, we do have, uh, Resilience 4J. So Hystrix, I don't know theoretically, but Resilience 4J is something which I've used. So Resilience 4J, unlike I mean, like, uh, Log 4J will help you, uh, have a complete log of what all has gone wrong. So that is going to help you in monitoring the, uh, failures while implementing your circuit breaker patterns. So, yeah, monitoring and logging will be a must here because you will have to understand that what has went wrong. So yeah. That's it.

Can you describe how to apply solid principle in Java based microservices application what is it? Can you describe how to apply solid principles in a Java based microservices application to improve maintainability? Okay. So solid principles basically, like, uh, like, here we are saying to improve the maintainability. So SOLID stands for different things. So s meaning single responsibility. Your class should have single responsibility or not multiple, uh, functionalities or responsibilities in it. Always open to, uh, uh, what do we say? Open close principle, basically. So it is open to extension or you can extend the functionality, but it is close to modification of the functionality. LS Liskov substitution principle, uh, where, uh, the subclasses can be used, like, wherever, uh, the base class is expected without, you know, uh, some unexpected behavior. I is, again, interface segregation principle. Here, that means we can split, uh, larger interfaces into smaller, uh, more specific, uh, interfaces to avoid, you know, unnecessarily, I mean, uh, all your classes need not implement all the interface methods. So if it is split up so whatever is required only, that will be implemented. And next is, uh, dependency inversion principle. Here, the high level modules should depend on the, uh, abstraction and not concrete implementation. Meaning, uh, dependency injection, we can use here during run time so that you can just pause on the objects and reuse the code. Now to, uh, improve the maintainability of this microservices, uh, application, uh, what we can do is we can apply all of these principles in the microservice which focuses on a single, uh, responsibility class. So if you are in your application, if you're having a class, it should just have one, uh, responsibility. Then it should, uh, utilize the interfaces very effectively. And wherever required, we can implement this interface segregation principle where if your interface is having a lot of methods, but then if you are splitting it up, I mean, if there's a possibility of doing that, uh, well, different interfaces for interaction is going to help. And other than that, uh, what else? Open close principle which we spoke about, uh, where modification is not allowed, but the extension of the functionality is still, uh, on. And inheritance should be, uh, applied very appropriately to adhere to the solid principle and how can I implement this obviously there should be loose coupling between the, uh, modules, then there should be a proper testing strategy to, uh, make sure that all of these, uh, things are at heard? And monitoring or, uh, maintaining logs of this does comes as a must in any application. So, uh, like to implement microservices, these all things is what I will apply or I will try to include in the application while development.

Detail the steps of integrating Python based AI models. Name what is it? Detail the steps for integrating Python based AI models into an existing Java microservices architecture. Python based AI models. Now if I want to Python, uh, frankly speaking, I've not worked to that extent. But, uh, as per my knowledge, I think to integrate AI based models, like, Python based AI models, In your existing Java microservices architecture, what you can do is, uh, maybe breast API we can use so that if you are having these AI models that can, uh, I mean, it's just a wild guess. We can create maybe a Python, uh, service. There is there will be a Python micro service, uh, which will expose to my, uh, Java which will be exposed to my, um, Java application via the, uh, rest endpoints. And, uh, I I mean, the application which is existing, the Java one, it can then communicate with the Python, uh, Python based AI models via this, uh, REST APIs. So it can at least have a communication between these 2. So that is one way which I can think of that we can integrate a Python based model in the Java application. Uh, because, like, if you have a rest API to access the, uh, Python based thing, you can access its methods and all the functionalities you can access via your rest API while communicating with them. So I think this is one straightforward approach. Uh, apart from that, some messaging mechanisms also we can use. Now since this is a micro service architecture, okay, we have messaging tools like JMS and all, but, yeah, in between these two, we can use Kafka. Kafka can be used where, I mean, some asynchronous obviously, if it is Kafka, it, uh, we can, uh, enable the asynchronous communication. And, uh, the Python, uh, model, maybe whatever messages it has, it can send it to the topic, uh, I mean, the Kafka topic which we have, and the microservices, uh, I mean, my Java application can subscribe to those topics and then consume those messages. So this is one way which I can think of at the moment. And steps for detail the steps for integrating. So one way is the communication between this. And then for deploying these applications, we can make use of Kubernetes, uh, for scalability and orchestration, or we can use Docker. Like, for if for a simpler version, Docker can be used for the deployment. And packaging all of this together, again, Docker can be used. Or, uh, yeah. I think that's it. Because Python, I have not explored that much, but, like, with the common, uh, concepts which, uh, I'm aware of, I can think of all of these things. So, basically, you'll be implementing rest APIs or message broker, something is which we'll use to communicate. Then for deployment, you can use Kubernetes or Docker, uh, for the setup. And for packaging also, Docker can be used.

Explain a strategy explain a strategy to ensure 0 downtime deployments in microservices using Spring Boot. Zero downtime. Okay. So microservices, any which ways individually your services will be deployed. And 0 bound time. So Okay. Um, Docker to me. Kubernetes is going to create a Docker image will be there. Uh, no. We can make use of, uh, Kubernetes here, like, to ensure a zero downtime deployment, some rolling update kind of strategy. I'm not aware that much on the infra part, but, uh, I have come across few things in my previous project. Uh, rolling update strategy, I mean, with, uh, Kubernetes can help us achieve this, which is a zero downtime deployment, uh, where, uh, you know, new versions of microservices are gradually rolled out to replace the existing ones. So in this, uh, way I mean, there's no downtime required, and any which ways it is gradually going to update a newer version. So in that case, you need not have a downtime, and your application will not go down for a new deployment or for a new version to be, uh, deployed. And, uh, obviously, uh, maintaining graphics on a production environment or on any environment, you will be having some managed servers. So, uh, this rolling update obviously can be done maybe on some managed 1 or managed 2. Some of the other server, and that can happen in parallel and then the URL will be redirected to the servers. So that way, uh, the l checks and everything can help us achieve this. So, uh, Docker, when we use, we kind of create images of the application, whatever we have. So, uh, that also helps us in, uh, not having a separate deployment altogether. Load balances is something which I've already mentioned. Kubernetes, like, if you're using for deployment, it will help, uh, to manage the life cycles of your, uh, microservices including the rolling update.

What Python tools and frameworks would you employ for monitoring, logging, the health of microservices? Uh, Python. What Python tools and frameworks would you employ for monitoring and logging the health of microservices? Oh, no. I am not aware of this, but I've heard of few tools. I think, uh, Grafana and Flask being one of them. Those tools or frameworks you can, uh, use here. What the Java tools and frameworks? What do you employ for monitoring? Because in, uh, Java applications, We do have, uh, different frameworks. Like, obviously, you have your spring boot and then that you have different mechanisms to maintain the logging and monitoring. But in Python, I have not, uh, developed much in Python. So I I, uh, don't know in-depth answer for this. But there are few tools which I have read about I mean, I have I know about, uh, Flask being one of them. Then Flask being one of them. Prometheus or something, uh, is there. I don't clearly remember. But, yeah, maybe that's it from my end for this, uh, question.

Examine the following Java code that is intended to lazily examine the following Java code that is intended to lazily initialize an instance of a service. Can you explain what is wrong with this code and what could happen if multiple threads try to access get service instance methods simultaneously? So this is something like a singleton. Okay. Public static gets okay. Private static. Fine. Public static service getting service instance. Service instance is null, then you are creating a new service. But, yes, there's a problem. Right? Public static service to instance. So what okay. So I, uh, will just attempt to answer this question. So here, we are trying to, uh, lazily initialize an instance of the service. So we are trying this is mostly a code of a singleton design pattern. Uh, so where, uh, we are ensuring that for a class, only a single instance is, uh, gen initiated maybe created. And, uh, in this code, this is going to work, but not in a multithreaded environment. So in a multithreaded environment, if multiple threads are accessing this class and trying to do this, there, uh, there is a possibility that multiple instances will be created, which is going to, uh, break the purpose of your singleton, uh, design pattern itself. So in this case, there's one thing, uh, which is wrong. We could have had a synchronized block here. Like, the instance which we are checking, if you would have had on any, uh, additional synchronized block where the same thing we'll be checking. Like, if your service instance is null, then create a new instance, but that should be in a synchronized, uh, static block. So then that is going to prevent, uh, any issue in case of your multiple threads. So if multiple threads are involved, then you need to you ought to have a method which is synchronized and which is checking this. So that is going to prevent the multithreading issues which we might get in the get service instance method. So, yeah, that's it for this code. So, basically, the answer for this is, uh, the method is not synchronized, so you could have had a synchronized block, which is going to, uh, handle the multithreading issue.

What does this say? Given the Java snippet below, can you identify the problem with singleton design pattern implemented here and suggest how it could lead issues to a multi data environment? Similar. Okay? Private static singleton instance for the okay. Okay. Okay. So, uh, this is a valid code for a singleton design pattern. Like, in a normal environment where you do not have multi threading or multiple threads accessing this class at once. So this might work for, uh, the application where, you know, you do not have a multithreading kind of thing, uh, coming into picture. But then if it is a multithreaded environment and if multiple threads are trying to access, uh, this, uh, or trying to achieve the singleton design pattern, like, you know, only one instance to be created at once, this code is going to fail. So to overcome that, this is going to lead issues because since this is a public method, obviously, we have a private constructor. We have all the prerequisites which is required for a singleton design pattern to, uh, be achieved. But then in case of multithreaded environment, multiple threads can access the static method of the, uh, get instance, and there is a possibility that this, uh, singleton design pattern will break because multiple threads at once is going to, uh, access this method, and there is a chance of creation of multiple instances. So in this case, uh, can you identify the problem? The problem here is there's no synchronized block. So if I have one synchronized block here where I'm again checking the same thing that if the instance is not null, then only create a new instance. So the synchronized block is going to help me here, uh, to avoid issues in a multithreaded environment. So there should be a synchronized block here, which is, again, I mean, going to check the instance if it is null or not, and then only it will go to this get instance method and create a new instance. So, yeah, basically, it should have a synchronized block.

Device, uh, method to ensure consistent data. No. What is it? Device, a method to ensure consistent data across multiple microservices handling persistent data. Okay. So if you are having multiple, uh, I mean okay. Multiple microservices handling persistent data, what comes to my mind is, I mean, how to ensure device or method to ensure. I think, uh, saga design pattern can be used here because, uh, saga is something, uh, where now for example, if I take any app, maybe, uh, Zomato for that matter. So in Zomato, you have different services. Like, I can just for example, for the sake of this question, I can just consider that, uh, placing an order sorry. Viewing the, uh, menu, selecting, uh, the food, it is going to go and sit in a cart. So that is one thing. After it is sitting in the cart, I'm going to click on place order. And once I click on place order, it is going to take me to the payments page. And once I do the payment, that is when the order will be completed, and that is when I'll be notified that, okay, your order is completed. Your food will be arriving shortly, etcetera, etcetera. So Saga design pattern, what it does is, uh, it is going to ensure because saga design pattern what it ensures is, uh, it helps you to keep your data consistent because step 1, step 2, step 3, step 4. If all the steps are achieved, so 1 by 1, uh, like, then only it will get committed. If it is failing on step 3, it has to roll back from step 3 back to step 1. So, uh, in this, uh, scenario, the data is kept consistent. So it works like breaking down a very big microservices into smaller services, and it handles its own transactions. So placing sorry. Adding that food item in the cart, that is one service which is a doing, and it is updating the database. Apart from that, then, uh, after the card, I'm placing the order that is one service. Uh, so, uh, all these operations so database is getting updated any which ways. But in saga design pattern, when we are making use of saga design pattern, it ensures that the data is consistent. Because if it is failing at any one point, from that point onwards, it has to have a rollback strategy. So the data is not going to be inconsistent in, uh, this case. And to, uh, ensure consistent data again across this thing, obviously, you can have communication mechanisms also using some, uh, messaging. Uh, obviously, your microservices are going to communicate with each other using some of the other mechanisms. So that is one thing. But then to ensure that data is consistent, Saga design pattern, like, uh, fits the bill. It will, uh, take care of the data consistency across your microservices is what, uh, I can think of. And there's one more, uh, you can have, uh, distributed transactions that is also, uh, going to ensure your data consistency. Then there's another thing which is, uh, what else what else what else? Saga design pattern. Distributed transactions you can have. Then event driven approach is, uh, also something which can achieve it. But yeah. I will stick to Saga and the distributed transactions pattern to answer this question. So that's it from mine. Thank you.