Manikanta Dupam

Hello, all. This is Manikanta. So I have almost 10 and a half years of experience in the IT industry. My entire career has been in the medical sector. Currently, I'm working in Philips. Philips is my second company. I have more than five and a half years of experience in Philips now. Earlier, I worked in DataScribe at Forteck Private Limited for five years. I then joined Philips. Coming to my tech stack, I started my career with basic technologies, including JSP servers, plain HTML, CSS, Bootstrap, JavaScript, Ajax, and jQuery. I then improved and migrated to Struts 1, 2 applications, and then to Spring MVC, Spring Boot, and microservices. This is a kind of transition that has happened over my ten-year time span. I also worked with front-end technologies, including Angular JS, and more recently, Angular and React JS, which follow framework-oriented architecture and require us to follow certain design principles as per Philips' standards. Coming to my current role, I work here in Philips and have almost 10 to 12 developers under me, including 1 or 2 testers. I am involved in end-to-end architecture and lead positions, including entire system design, database design, and collaborating with other architects for feature refinement sessions. We follow SAFE Agile as well for our daily work. In that process, we have to plan for PI planning and sprint planning. We drag and drop functional requirements to technical requirements. Later on, I create diagrams or workflows in PDF or PPT format depending on the feature level or feature size. I also continue to communicate with the ARCA team for decision-making. Some doubts we may have are good for having good feedbacks and all that stuff. Even though I'm in a lead position, I still want to be involved in individual contributions from my side. So, 60 to 70% of my sprint will be dedicated to development activities. I will make sure there is at least one user story equivalent to other developers, but I may finish my user story a bit early and support the developers in the remaining time span. Approximately 30 to 40% of my time will be spent guiding and mentoring our team, and the remaining 60 to 70% will be spent on my own work. I really believe that when I pitch in and help the developers with their issues, I can understand their problems easily. Instead of just guiding them, if I'm involved in the development task, I will understand what they are facing and can help them more effectively.

there is a chance of early rectification and that's where we can avoid wastage of our productivity. Yes, this is me.

What considerations would you keep in mind when, particularly, it's based on the requirement. I will be checking what whether we need to have a one instance or multiple instances, what is the size of my microservice, which database I should use, whether I should go for cache or NoSQL or SQL. And, so what are the configurations needed? Should I communicate my service to any Kafka, any other microservices using Kafka, HTML, what do you call a REST template, communication, all those stuff. So, basically, it will be like that. It is not like a typical monolith application works. So, we will be considering based on the authentication, basically. Watch what authentication we need to have, if any security. So, one authentication token can prove for multiple microservices or not. And, if my microservice fails, what is the action I should be taking? Any circuit breaking system should be introduced. All the stuff, like, we need to have a consideration when we introduce the new microservice in the existing ecosystem. Particularly, Spring Boot and in Java, so, most cases, like, what are the first things we need to use, whichever the latest versions our team has, hands on. And, should we use Liquibase for our application? And, so, most probably lightweight databases we will use because it's a replica or small chunks, right, microservice-based. So, we don't need a very big database for that, like Oracle or SQL Server or some. So, post ASR, MySQL should suffice. And, should we go for JPA or JdbcTemplate? If it depends on the demand for more collaborations in the microservice, of course, we will use JPA. If it's only select queries, something like major joining, sir, major queries if you are doing, then we better go for JdbcTemplate. And, if there are any dynamic queries or processes, business logic, you can write this kind of things, we'll go for JdbcTemplate instead of JPA for select queries, it will be much faster, I believe. I mean, it is proven, and then, all the business structure, everything, we will use.

Detail the steps for integrating Python based AI model in the existing microservice architecture. So, basically, Python based AI models into the existing Java microservices means so we need to have a dependencies to be added to our existing service and which

So, did Python-based script automate health checks across the network of Spring Boot Microservices? Health checks in the sense, what we need to do, we should have multiple so there will be 1 microservice, which we included in hell, Python inside 1 microservice, maybe, let's say, MS one. And in that MS 1, we can think of multiple microservices running. And there will be some other servers, different servers, basically. Not it's not may not be a microservice. It could be some other smart link and some other database activities or some different port numbers. Kafka is up and running or not. And any Cassandra, Redis, Cache, all the databases, this kind of information, if I want to validate, so we need to have something like how we used in Java threads, create all, how many types which first we will define. Let's say, 15 different ports I wanted to utilize, so I can use executor service in Java. Similarly, if anything's there in the Python-based script, we can implement that and define all 15 sizes and submit once and get the response maybe using features or something. And once the response has come, that entire health check will be tracked based on the services' returns for each individual. Just like a service is returning a 200 or not 200, then we are good for that service. Okay. It is up and running, and it is giving the response for us. We can still have each service, some endpoints keep active. So for that, we may need to consider some of the things like authentication tokens should be used for validating all these 15 services. So that's how we need to pass all that stuff, we need to take care in the process.

Discuss methods to optimize Java microservices for performance in Spring Boot driven environment. So, basically, if any Java microservices for performance methods means, let's say, if in your method, you're doing almost 5 to 10 insert queries or something. So, we will define it as having one method segregated. And if out of 10, 2 or 3 belong to one particular model, put that entire model in one method and call the remaining things. So, what we can do is create a separate class and write all 3 methods in that and call from here and one of the main service methods so that all these performance things will be optimized. By this change, we just segregated based on the coding standards for how performance is optimized. First, we need to see any deep database side. Any normalization has to be supposed to do. If there is no need of any normalization, like properly indexing is there, the database indexing is there, or anything related to indexes, queries optimizations, and all the tables are properly joined with proper columns. And most mostly, you know, use the query instead of select star. Use select variable name. Where to use JPA, where to use JdbcTemplate, which I said earlier. And so, use the better approach in terms of iterating. So, don't use more number of collections. Use JSON array, JSON object, or object mappers instead. If you use more collections, you'll end up filling up your Java memory just like anything. Like, if there are simultaneously multiple users logged in more than 10 to a100, then your collection memory will go up like anything. So, we need to avoid that by using this kind of JSON array, JSON objects. And instead of using a lot of strings for appending, don't use strings for appending. Use string builder, string buffer, something, which will be more positive. And where to use streams, where to use normal for loop, while loop. These kind of things we need to be considered in our day to day development tasks.

Given the Java snippet below, can you identify the problem with singleton design pattern implement here and suggest how it could lead to issues in multithreading environment? So if the multithreading environment let's say I call the singleton class. So, I call singleton dot get instance. So wherever I call first time, I started with one of the service one. Okay? In the service one method, I have create I have called this singleton dot get instance. Then it will return only one instance. Fine. Next time, again, if I call the same instance, it will create. First time, it will be null, and next time, it will create a new one. Whereas, in the previous example, I said how to create a thread, multiple threading using executor service. Let's say I created executor service 10 times, and all three, 10 times, I'm calling the same method, which internally creates, calling this, singleton dot get instance. So what will happen? All 10 service 10 threads hit this class simultaneously, and which, there is an issue, like, out of 10, this if condition will be reached by at least three to four threads by the time all 10 threads are running simultaneously, then there is a chance of, instance, if instance is equal to null. That condition, wherever it is there, all four threads will be in that place, and then the instance has been created. Later on, again, other threads, if it is already started a little bit later, it will get the instance. That is secondary. And then in that case, these threads will get, could lead to an issue. So to avoid this, we can use a synchronized block. So inside that singleton dot get instance method, enclose that or put this method as synchronized, or inside that method, synchronize the block, open brace, and put that if condition inside that one, and then return the value inside itself. So that what will happen, out of 10 threads, how many threads will you call simultaneously? If one thread is accessing that particular block, it will stop that from there. So this is how we can avoid the multithreading, may avoid the singleton issue during multithreading problem.

So here we review the block of Java code for restful service. Can you spot the issue that might arise from the exception handling and suggest how this could potentially compromise the web service robustness when an exception occurs? So, rest controller request mapping User service. Okay, get all users list. Final users return. New response entity. And new response entity. Underdog, okay, catch exception. New response entity is not in server error. So here, we shouldn't be using a generic exception catch like exception. So, find all by users. What exception will it throw? Usually, JPA doesn't throw any error. If I write any JPA queries like find all users, it won't throw any error from there. Either it is empty. If it is no record one, it will be empty. If the data is there, it will return some values. And, whatever the result is from the service user service, so what exception is throwing, it should be precise so that it won't need to compromise and further potential issues. Like, if you have generic things, it's not the recommended one. So we can have multiple cases inside catch like, whatever exception, bad exception, NullPointerException, or SQL exception. These kind of exceptions, we can still put using pipelines and catch them in the controller. Our best way is to use a controller advice in the Spring Boot. So, and using controller advice annotation and with the @ExceptionHandler annotation. Based on that, it is very easy. No need to use try-catch block also here. Just define that and define any separate class, exception class, and write our own exception handling controller advice. So whatever the controller returns the error, it will automatically catch there and streamline the process so that no need to write everywhere the same piece of code like internal error. Because whatever error comes from service or anywhere else, that will automatically read based on the service code. I mean, HTTP status code. Yeah. That will be returned from there and same status code, and we can still use error code resolver also. Like, how which format I wanted to use for NullPointerException or some bad request or internal server error or server not available error, whatever. So based on that, we can write each separate method and return the unified or generic way of exception handling. That is the best approach.

So, to develop a comprehensive backup strategy for a microsystem ecosystem that spans multiple data sources, we can achieve that by going for distributed systems, basically. So, multiple instances of the same microservice are running. If one service server is down, automatically, that instance will be taken down. We can use load balances or some Kubernetes configurations for that. We need to scale up based on the users, see the inflow of the users and expected users, and create or add more instances accordingly. Because in a day, there will be less users' issues, and in some point of time, there will be huge. That time, we need to have more services running parallelly. We need to tune and configure it accordingly and monitor. We need to keep monitoring which service is getting delayed in terms of responses. So, that will automatically get down in terms of priority, and try some restarting mechanisms. If that didn't work, then someone will send a notification to the developer to take care of it. And if all other remaining services are running normally, those requests will go like a round robin algorithm. It can utilize more performance-related features. If any services are taking quick responses, that service is like a high-priority service, and all requests will send to that, and responses will keep coming from that. So, it's like a priority or a performance-oriented thing. It will be utilized for that. Thank you.