Aravind Malla

Yes. Hi. This is Arvin. I'm born and brought up in Sri Lanka and Andhra Pradesh. It's been 7 years. I'm into back-end development, and my current company is the second one. Both are in Chennai currently. My studies – I had studied B.Tech in computer science from Amrita University, Coimbatore. After that, due to campus placement, I worked in Symantec. It's a security and cybersecurity product, and it also gives both B to B and B to C products as well. And my current company is Zoom Rx Healthcare. I have been working with multiple technologies, like JavaScript, Python, TypeScript, and a few frameworks of these languages. I've always been passionate about these things and I'm working on being an architect in back-end development, which we're not really referring to in the technical world as back-end, but rather web applications. Thank you.

Implementing error handling and retrace for failed API calls in microservice communication can be achieved through the following steps: We would implement error handling and retrace for failed API calls in microservice communication by using a combination of retries and circuit breakers. To handle token limitations, we would implement a retry mechanism with an exponential backoff strategy to wait for a minute or so before retrying the request. This would prevent the server from stopping and ensure that other requests are not lost in communication. We would also maintain 333 different keys and use a load balancer to distribute the requests across these keys. If one key fails, we would try the next key, and if all keys fail, we would log the details and come back to verify. In Java, we would create business-level exceptions that wrap technical-level exceptions to identify the type of error and determine whether it can be resolved by retrying the request. We would set a threshold for the number of retries and if that threshold is crushed, we would come back and verify. To implement this in code, we would use a library like Hystrix or Resilience4j to handle circuit breakers and retries. We would also use a logging framework like Log4j or Logback to log all the details of the failed requests.

I am really not sure about the saga pattern, but I will discuss the coordination between microservices. There are different ways that microservices can communicate with each other. If we use gRPC calls, they are faster compared to other calls. gRPC calls are one way of communication. Others are HTTP, or we can use GraphQL. These are a few communication methods, and a few more, such as using pop-up notifications to communicate with each other, or having a master-slave architecture so that the master determines which slave to call next. That is one thing. And, yes, these are a few ways we could implement the coordination. Thank you.

We would implement the status of "Active" and "Inactive" with a "Scheduled" status for microservices that need to be started at specific times. This would allow us to scale security for multiple Java microservices. For example, if a microservice is used on a daily basis and we know how many requests it will get, we could put it in a workload and it'll spawn the required number of instances. And if we think a microservice should be started only at particular instances or some triggering should happen, we can use the latest Kubernetes server. So when the notification comes, it will spawn itself and do that task and close it off. This will save cost and resources too. For example, if a microservice should be run every day at one particular time, we can use some scheduler provided by cloud services. Using that scheduler, we'll just start it, and it will close down based on those services' capacity and the kind of resources it uses. We could also use AWS Lambda or Cloud Functions for serverless computing, or data flow if we are focusing on batch processing. These are few strategies, I would say. These strategies are already implemented in forms of tools, so if we get to know those tools, we'll get to know the strategies as well.

Can you outline the process of creating a doc file? Java application. I believe it should be a is there a task that's been a while I didn't, work on this? But, yeah, I have used my own Docker file, but, it could be a simple command or as such. So, yeah, not sure about this.

Can you guys hear how people integrate React into a Spring Boot project that we'll be doing? How would you integrate React into a Spring Boot project? React is based on a request or with a change in state, so it should start rendering. Not sure. Never implemented that in Spring Boot.

We'll try to add an element to the list. It is not a list of 1, 2, 3. We'll create a list, while instead of initializing a list, I mean, while declaring it, we should specify what kind of list it is, what data type of list it is. Since that is not present, this might lead to an exception.

We create an interface for logging. And based on the selection, we'll see which logger should be used, like console or file or anything. But on a high level, it's better to create a logger interface. The issue with the original statement is that it uses filler words ("", "") which are not necessary. It also uses the word "log" multiple times which can be simplified to "logger". Additionally, the phrase "I mean" is not necessary and can be removed for clarity.

To me, to say, the CSCD pipeline allows for multiple branching, so, for example, we have release, master, and develop. And based on that, we can do some things. When a person needs to update a feature, he'll create his feature branch. Once that is tested, he'll put it in the development branch and put it in the development environment. And once integration testing is also done, then that branch will be merged to the release branch, and we do the release. Once everything is good, we can just move that to master.

So these optimizations for a Java application that leverages both relational and NoSQL databases for different types of data processing. Both relational and NoSQL databases are used for different types of data visualization. The optimizations for a Java application. One good example is, for instance, if we take MySQL as a relational database and Elasticsearch as a NoSQL database, and we are creating a chat application. In the chat application, we'll use Elasticsearch. We'll put all the content in Elasticsearch. I mean, we have some documents, and all these documents can be stored in Elasticsearch. Just the text will be stored in Elasticsearch, and we have users to track users and proper structured data. We'll use MySQL database. During the chat application, based on the question, we need to check which document is applied for this question, and we need to reduce those documents. To retrieve those documents, we can use Elasticsearch because MySQL is good for retrieving structured data, but paragraphs or contents of a file and ranking them based on the given query. It's better to use a NoSQL database and get the data and give it to the user. So that will track what data we have given to the user in MySQL. So, here's one way we can implement optimizations. Actually, optimization is that we should not store redundant data here and there. For NoSQL databases, like the IDs could be stored in the MySQL database for any document. If a particular document is required, we'll check for that ID and directly go and ask in query in the NoSQL database rather than doing a search. So, basically, NoSQL either we can use Elasticsearch or DocumentDB for blob storage. This kind of blob storage will help us to drill the data.

Set your approach to implement a resilient transaction management system in the microservice leveraging Spring Boot and message tools. Transaction system in the microservice service in Spring Boot and message queues. As I mentioned in one of the earlier questions, communication between microservices can be done via SaaS or SQS, that is also one way of doing it. So, by using message queues, a Spring Boot application will keep checking if a message has come or not. If a message comes, it will start processing the data. And once a message is received, Spring Boot should acknowledge the message so that if we have multiple instances of the Spring Boot application, other instances can also take that message. For instance, if the Spring Boot application is down and the message is there, and somehow due to some error, it goes to a dead letter queue, we should have a mechanism to verify the dead letter queue. If the data in the dead letter queue is valid, we'll process or log those messages.