Akanksha Panchal

Yeah. So, my name is Akank Shavanchal, and I am working as a principal software engineer at Dell. I worked mostly as an individual contributor. I also have worked as a team leader in the past. I worked, so my responsibilities are mainly to implement back-end, APIs, and end-to-end region implementation, primarily focusing on the back-end implementation. I use technologies like Java, Spring Boot, microservices, SQL, and Hibernate, as well as other supporting frameworks that are needed for the Java Enterprise application. I have worked in both monolithic and microservices architecture, and I'm familiar with design principles for systems, which go into while designing any new application. So

Elaborate a Python utility that could dynamically address microservices based on based on system load. Okay. So I have I haven't worked with Python, but I worked with Java or Microsoft Business. So I'm unaware of any such utility, which goes, which is available.

What's the approach to identify and resolve a Spring Boot application startup failure to creation. Okay. Let me think about it. Identify and so any Spring Boot application or Spring application would be so that can have unidentified bean exception by startup because that bean in which we are expecting to be available or which is getting injected somewhere or getting auto-wired somewhere that is not available with the application for us to use. So in that case, mostly beans are created with class name, and we would go there and identify how we have annotated the bin if we have annotated it right or are we using any other qualifiers over there for bin creation. So, we would make use of it. And what happens is in case of multiple beans with the same name, the place we are auto-wiring or using, we need to use a qualifier as well just to resolve the ambiguity. So, that is one of the approaches. I would check for the bin name or the class name causing the issue. And, I mean, it would be no such win definition kind of exception. Also, we would check if there is a dependency chain, if there are beans which are dependent on other beans, so we would have to trace back till that point. And we can also run the application and debug with debug logs for us to get more information. The common causes are actually the annotation missing and misconfiguring of the bean, or there is also sometimes circular dependency as well. So, or maybe the bean scope is very much limited. So, we would check if we have mentioned any of that. That would be my approach to deal with any independent startup error. And, also, of course, if there are third-party means which we are using, we would have to check for class path for the dependencies.

Again, I haven't worked with Python, so I cannot really answer on the tools and frameworks available for monitoring and logging, the health of microservices. But, in Java, we have ELK and other stacks and some monitoring logging tools, which we use with the application.

Yeah. Just want to get it out of scope for me because, like, Python-based AI models, I'm not aware of, so I would skip them.

0 downtime deployments in microservices using Spring Boot can be ensured by having a backup application available, a load balancer configured, and implementing the circuit breaker pattern. 0 downtime means there would be a backup application available or something like so, downtime does happen in the primary application, and it does happen for any issue in the primary site. So, we normally deal with it by having secondary sites available for the application or basically backup applications also backup servers available where we have deployed the microservice. Specific to Spring Boot, we can make use of a load balancer configured, which we have done for one of our applications. In the load balancer, if there is a particular request that is not solved, it could send the request to the next in the cyclical order, and it would send it to the next server. We can also have Spring Boot's actuator, which provides health check endpoints so that we can make use of them. If the application's health is not as per the parameters, then it can indicate us. Then, there is another secondary deployment of the same application. And there is one specific design pattern called the circuit breaker pattern. This pattern is meant to serve zero downtime. It uses history and breaks the circuit to the unhealthy instance. If it has identified any such instance, it would not send the request through that. We can implement the circuit breaker pattern also. These are some of the ways to deal with downtime in the application, including monitoring, alerts, and logging.

Name with the block of job or for. Can you sort threshold that may arise from exception? And you suggest how this could protect the web from slow business when an exception occurs. There is a rest controller, and then there is request mapping, which is for API users. Then there is get mapping. Then there is get all users. So, that will get all the users. And then if it is not able to get all users, then it may throw an exception over here, and then it will say, okay, from this method. From this method, we just put down from this method, or catch and then return an exception. So, this response entity, the runtime exception, when it occurs, it, before that, I could see one compile-time exception also. In the method declaration, the response entity has to specify a generic, and within those, there is a missing bracket for specifying the generic before, or like, public response entity is not right, and then get all user is fine. So, once we do get all users, and the list of users will get assigned, then users would be sent as a response entity. But if we are not able to get, we would be catching the exception, whatever it is. So, a parent exception, we are catching. And then again, we are forming a response entity with the error, which is an error code, internal server error. We are not showing any message over here. We are just showing the code is internal server error. So, it will show internal server error over there. And then wherever we are calling this find all users from, we are doing get all user. Then in the service implementation, since there is in the user, okay, user classes, they are user service, okay.

This is the corrected transcript text. Okay, so if multiple threads, this is an implementation of single time. And if we try to lazily initialize lazy initialization means, first, we are checking that service instances are not available. And if it is not available, then we are assigning up. But if multiple threads access the get service instance at the same time, since there is no synchronized use over here, multiple threads would be able to execute this code, which is inside the method, which is if, inside the if block also. So what will happen is that multiple new service method new service object would be created. And the service instance will be able to point to only one at the end, but then again, we would have the for what we would have to return which is service instance. So the singleton pattern will be broken over here because we wanted to have only one object of this, and we did not want others to create unlimited objects. But if as many threads let's suppose 3 or 4 threads come together to get this instance, then because this is not synchronized, it will be able to create as many objects as the threads are. So for that method, we can actually make use of synchronized keyword with the method or with the block, so that and also we can implement a double check method over here to overcome this.

Then we have a comprehensive backup strategy for a microservices ecosystem that spans multiple data stores. Comprehensive backup strategy. We may answer this screen if this happens. Got it. My laptop is still just a screen. So with multiple data stores, what I see is that the application will have to create connections with these data stores every now and then. And then we have to fetch data from multiple data stores because the data is not all in the same place, which would be an interdependent task to fetch data from all of them probably for a single API. We might have to contact multiple data stores. So I mean, there has to be consistency, availability, scalability, and ease of recovery in all the data stores. So how do I design a backup for it? Backup for backup, we need to have a backup for each kind of data store. That is what I'm thinking of. Like, for relational databases, there would be a logical backup, such as a dump or something. And there could be a cloud-based backup or a replication backup or a high-availability backup kind of thing. And for NoSQL data stores, we can have snapshots available of them, okay, for the recovery purpose. But yeah, so I discussed MySQL and NoSQL, then there could be message queues. So again, for message queues, there has to be a different strategy, like a parallel queue or something.