Saikiran Vallepalli

Myself, so I can hold 8.8 years of experience. I hold 8.8 years of experience, and currently, I'm associated with IBM Tech where I will integrate different suppliers of games into a technology system. I will integrate the different suppliers of games into a technology system, and I will be associating with the product owners as well as gathering the various suppliers' requirements. Post requirement gathering, we will start the development activities by reviewing the Java code and rating the API services. We will then take care of end-to-end development to deployment activities. Each integration as a senior developer will be taken care of from end to end until it's deployed into the live environment. I will also be like, if any production issues occur, I will jump into the production environment and check the logs to see where the issue occurred. Based on that, I will verify the issues and then, if necessary, we will fix those issues and redeploy into the production environment. Currently, we are using a tech stack of Java, Spring Framework, and Oracle DTVS database. I have previously worked on Spring Boot and microservices. Yeah. This is about my background, and also, we will be using tools like SonarQube for core quality, Jenkins for deployment activities, and we're using Tomcat servers. Currently, as a senior developer, I will be mentoring 2 to 3 junior members. I will be reviewing the code they have written and giving suggestions if anything goes wrong in their code. I will be giving suggestions on what needs to be fixed and what needs to be enhanced. These are the kinds of activities I will be doing as a senior developer.

Yes, while writing code, we'll be checking if any conflicts were there in the merger while merging into the feature branch. With the feature branches, we'll be merging into them. After reviewing that, after reviewing is completed, then it will be completed by us. We'll be merging into the parent branch. So while doing this, we'll be checking how if any mergers were completed and if any merge conflicts are there before that. So we'll be checking on that. So based on that, we'll be resolving any merge conflicts. And also, our code will be checked while pushing into the Git repository. After pushing into the Git repository, we'll be running the SonarQube scans. So based on the SonarQube scans, it will suggest our future branch. SonarQube will scan our future branch. So based on our future branch, what are the commits we have done? So based on that commits, if they're based on SonarQube results, we'll be committing, modifying the changes and fixing those vulnerabilities if there are any fixes, and we'll be committing it to the parent Git repository. And also, without the solar eclipse, we won't cancel the merge. After passing the solar script, we'll be merging into the actual parent repository. Before that, we'll be committing and checking into the future branch, and running the scans to ensure the high quality of the code. And also, we'll be checking if any object creation was done, if any object creations were done, and if any threads were used, if the thread pool was shut down or not. We'll be checking these things, and we'll be committing into the Git repository.

Concurrent HashMap works in multi-threaded environment. Yes. Concurrent compared to HashMap, concurrent HashMap is thread-safe. Is thread-safe? Like, in the concurrent HashMap book, it is based on segment locking. Whereas, it is based on segment locking. So for like, for reading operations in concurrent hash map, there is no locking mechanism required. But for if you are updating while iterating or something, we are updating, the threads will be locked into the lock particular segment like concurrent hash map will be divided into segments. So if you want to update some particular thing, so the segment lock the thread will lock a particular segment in the concurrent hash map. So it ensures that it ensures by this a concurrent hash map is thread-safe. But when compared to HashMap, it is not the HashMap is not thread-safe. Even though we can make HashMap as thread-safe, like Collections.synchronize, we can use. But locking mechanism by using synchronize, the entire hashmap gets locked. Whereas in concurrent HashMap, only the particular segment which we are iterating and modifying will be getting locked. And the concurrent hash map is kind of like fail-safe iterator. Even when you're iterating and we are trying to modify it as well through concurrent modification exceptions. And moreover, in comparison to HashMap, in concurrent HashMap, null keys or null values are not allowed.

This would migrate an existing camera. Cloud. It's yes. In a monolithic, like, the question is related to monolithic and microservice architecture. So the monolithic architecture is a kind of architecture where we'll be mapping all the services into a single system. So, even if you want to change one service, we need to redeploy all the services again, and we need to make the application up where so it's every time for a small change, we need to deploy all the services and redeploy again to make the application up in monolithic architecture. Whereas, compared to microservice architecture, we'll be segregating, like, decoupling of these services into each and individual independent services. We'll be decoupling these services individually. So even if there is any one failure in the service, the other application won't get stopped. Only the particular service will be showing as failed, so the application won't go down. And also, by this, we can achieve boilerplate code reduction, and also main durability is easier when compared to monolithic architecture. And also, when you migrate to microservices, we'll be following certain rules when we convert into microservice architecture. Like, we'll be creating one service registry that connects all our microservices to the service registry. And through service registry, we'll be checking whether all the services are up and running or not. And also, we'll be implementing an API gateway. So, rather than hitting each and every microservice, instead of that, we'll be making a common API gateway. So all the incoming requests will come and hit into that common API gateway. Based on that common API gateway, we'll be writing different routing configurations. So based on the request, we'll be routing into the different microservices. And also, in the microservice architecture, we'll be writing for fault tolerance and the fallback methods. So if any service goes down, we'll be writing the fallback methods. So based on the fallback methods, we can know which services are up and running and which services are down. So, in this way, we can do the microservice architecture kind of thing. And also, microservice architecture allows us to implement several design patterns, like API design patterns, event-driven microservice architectures, and others. We can convert our monolithic application to different design patterns based on our requirements or feasibility.

We'll be integrating Kubernetes with our Spring Boot application. We'll create Docker images based on those images, and then deploy them into Kubernetes. We'll identify the load of those services based on the traffic they receive. Based on the load, we'll scale up or down the number of replicas of the service. If we experience a sudden increase in requests from AWS, for example, thousands of users, we'll enable auto-scaling in Kubernetes to handle the increased load. I'm aware of the basic level of Kubernetes, but I'm not an expert in Kubernetes architectures.

In the application, how do you implement error handling and retries fully be causing a microservice communicator? So in the microservice architecture in the Java application, we'll be writing several fallback methods. In the fallback methods, if any services are done, we'll be checking the service registry. And with the service registry, we'll be checking all the services, which of the services are down, and which of the services are running. So based on that, we'll be implementing if any failures happen while connecting to the service, we'll be implementing those things in the fallback methods. And, error handling, what we'll be doing, we'll be metering errors. We'll be creating our custom exceptions. In the custom exceptions, which are to handle this globally in the Spring Boot, we'll be using a controller with annotations and also response entity exception and handler classes will be written to handle the exceptions globally in the Spring Boot application.

Look at this Python course in many of the microservices. Hold on. Is there a solid principle being more like today? So this should be made.

As a list was already initiated with the list. So if you want, if you're trying to add some as we are trying to add this, so a new list, we are getting this exception actually. Maybe, like, this is exceptional because when we try to iterate over the list of it and if we try to add the list one of the elements, we'll be getting this runtime exception.

Present time of course to reflect a monolithic application to Microsoft credential 0. Maybe, we can migrate the model with the architecture rate to the microservice architecture, like different patterns. We can use circuit design pattern and APD set pattern. In the API design pattern, we may take a common IP, gate based on the common gateway, it will handle all the requests. And in the circuit design pattern, if any of the services is in the circuit, if any of the services is done, we can say that as a crisis in the half-open state, if any of the services is in the flow state. We can also use other design patterns like orchestral saga design pattern. The saga design pattern will have orchestral design pattern and choreography design patterns. If we implement these event-driven architectures, we'll ensure zero downtime.

Continuous testing strategy for the Java application using JUnit plus multiple stages. So we'll be using JUnit. Like, we'll be writing the JUnit cases here. Suppose we'll be integrating the CICD process, we can integrate the SonarQube tool into our CICD pipeline. So based on the CICD pipeline, we'll be integrating the SonarQube. So whenever we come in, whenever the deployment comes in, and the CICD pipeline goes through the SonarQube phase, then the SonarQube here gets to run the code. So it tests the code coverage quality and also, like, it scans for SonarQube blockers. If there are any blockers in the code, major or minor issues, it will scan for us. So based on that, in every stage, when we go into the first stage, we'll be committing into that development stage. So the development stage will be integrating into the CICD pipeline, so it will be running. So after that, if it is satisfied, then we'll be moving into the next stage, like the QS stage. So in the QS stage also, once again, we can implement the SonarQube scans. So based on that code scanning, in each integration step till the production stage, we can achieve this way by integrating the SonarQube into our CICD pipeline, ensuring the code quality. Suppose we can achieve code coverage quality like 80% or 90%, we can declare and configure in our code. So based on that coverage, we can check in the different stages and proceed into the next, like, development to QA to production.

So based on relational databases, we'll be using a schema and tables. There's a new SQL database. We can use a MongoDB database where we'll be variably using directly dumping our JSON. It has no structure and directly we can dump the JSON into the table and check it. We'll be checking this way. Maybe we can use MongoDB for different data types of processing.