Vrushali Sambhaji Ghadge

Okay, firstly, thank you for considering my application. So I have total 7.3 years of experience. Within that, I have worked in finance, big data, and ecommerce domains. So, currently, I'm working with Modular. So, it's more than 2.3 years right now. So it's kind of like a UK and European based payment product. So we are releasing an API so that users can use that and create, receive, and manage their transactions. So within that, I'm a co-working member of the internal portal used by Modular, called the admin portal. So that portal is specifically used for handling the payments internally, reactions, if any of the payments are being failed, if we want to reprocess any of the payment or if there are any issues related to accounts or customers or beneficiaries, that's being handled via the admin portal. Other than that, there are a lot of internal activities which payoffs ops and compliance users will require that have been handled by the admin portal. So, within that, like, what is the front-end technology we are using? We are using Spring Boot microservices, and in automation, we are using a combo framework. And for deployment, we are redeploying the services on Kubernetes services on EKS clusters on AWS. I'm working on all of these technologies right now. Other than this, with my previous organization, I worked with HP on their biggest program, which we call the InfoSite. This is specifically used for server management. So whatever our servers came into HPE's clusters, they can use the InfoSite portal and for forgetting analytics of other servers, if the storage has been less or if any updates have been required, if any of the servers are in risk or any compliances need to be applied, on any of the servers. This is the kind of portal HP has introduced. Within that, we have written Golang collectors, which is actually working on two HP servers and collecting data on a specific period. Then we are ingesting that data using Java Spring Boot applications. Then we are applying some rules onto that data by using analytics. And within that, we are using a lot of databases like MongoDB, TimescaleDB, and Minio. So after that, we analyze the data into the portfolio. So in this application, also, I have worked on all the phases, right from the Golang collectors to the data analytics. And previous to this, I have worked on an ecommerce platform, where we developed and deployed the application based on PHP. This is all about me. Thank you.

Over rollback strategy for a failed transaction in a distributed Spring Boot application. Okay, so handling the rollback is that there are two ways of handling a distributed transaction. In microservices, we can use the saga pattern. Within that, there are two parts: choreography or orchestration. So, right now, in my current projects, we are implementing the orchestration. So, eventually, when you are considering the orchestration, it means the transaction has been managed via an event bus. So, if any payment has been made, suppose my payment has been made, I need to suppose one of the payment calls that has been created. Firstly, it will be checked whether the beneficiaries are correct or not. Whatever account identifier, whatever account-related information, like account number, IFSC, EMI, CR code, whatever, we are going to check that these should be valid. And after that, we are going to check the balance. And then once all these transactions have been checked, we can check whether that account is blocked or not. And then if the beneficiary account is not blocked, then we can initiate the transaction. So, suppose in the second step, while checking the balance, if the transaction has failed, or what we can do is that in the next step when all the checks have been passed and the transaction has failed, we can send it to an external service. What it means? Like, if I'm a customer of ICICI and the customer and I wanted to make a transaction to the customer who is located in SBI, who is having an account in SBI, that in that case, the ICICI customer needs to say that transaction to SBI via some external or some mediator. So, suppose my transaction is entered into the system, all the checks have been verified, but it's been failed when it's from the external services. In that case, like, you have already reduced your amount from your side. So, what you can do is, like, what we can do is, I mean, whenever the external service request has been returned back with an error message, you can create a message, like, to pass the message to the backward stages. This payment has been failed with this error message, and your payment state will be this one. So, whenever that failure message will be gotten to the backward service, it's going to be recorded that the payment has been failed. So, I need to revert that money whatever I have reduced from ICICI Bank. So, the transaction is going to be what we can say, reverted, and the status of that payment is going to be failed or in an error-prone state. So, whenever the user wants to reinitiate or reinitiate that payment, they can initiate, but by using the same payment ID and internally if required, then we can handle the payment accordingly. That last time the payment has been failed due to this external service. If the external service has been recovered, we can reinitiate that payment.

What approach would you take to handle exceptions elegantly in a microservices architecture using Spring Boot services? Okay. What we can do for distributed system handling is create some correlation ID or common ID, which can be used throughout the entire application process. It means that if I'm considering any payment flow, it goes through many services. But when the payment has been entered into the system, like, in the API gateway or in Apache server, we can create a unique ID for that payment. Like, my name is Vishali. My payment bill is my account ID ending with, for example, 1, 2, 3. Vishali 1, 2, 3, and my current date and time. So similarly, we can create a correlation ID, so it will be unique for each transaction, user is going to make. So that this way, whenever that transaction is going to come into processing, into multiple services, we can use that same correlation ID. So yeah.

We will apply the proxy design pattern in a Spring Boot application to enhance the functionality of an existing class. Let's see. Design patterns renounce the application of an existing class. Okay. Suppose we have an existing class and we want to introduce some new functionality to the controller class. So in that case, the client class can create a proxy of that controller class, and control access. It means controlled access. What we do exactly is that we provide controlled access to the client. So we create a different interface or class, which is going to be a proxy, and it's going to provide only a limited API of our existing functionality. Right? So, within this, suppose I have a Student class, and my existing APIs are get student details, then get marks. My new model has come into that same student class. I want to introduce get course associated with that student or allocated to that student. So this functionality we need not to provide to all the API clients or consumers. Right? So within that case, we can create a proxy class, and within that, we can only introduce the APIs, which we want to expose to the external world or clients. If we don't want it to expose the functionality, then we can use the proxy class.

Can you use a device to handle a situation where two microservices in Spring Boot attempt to modify a shared resource simultaneously? The solution can be synchronized. We can use synchronized lock, within the resource we are accessing. Suppose I'm having a file which users wanted to access, and both services wanted to access in that case, I can first apply the synchronized block onto that resource so that two services are not going to access simultaneously. The second thing is that we can provide a time out to vetting. This means that if one of the microservices tries to access the resource and the resource is not valuable, then we can wait for a specific time amount of time. If I'm trying to access the file system, then maybe if I'm not able to retrieve it, then I can wait for maybe 10-20 seconds, maybe 10 seconds. And then again, I can retry, up to a maximum rate we can define. And if we are able to do that, I think the problems we are going to face related to retrieving the resource simultaneously can be avoided.

What step could you take to refactor the monitoring Java application into Spring Boot Microservices architecture? Okay. So, what I can do is, like, we can divide our application refactoring into 3 to 5 parts. First is how we are going to migrate our application. Firstly, we can consider what are the business requirements. So what are the important business units or modules which business will be required to work smoothly, so that we can prioritize our tasks accordingly. So once that is done, we can divide our application into multiple modules or functionalities. That means the functionality. So based on functionality, we can divide an application. We can create a specific design document, and then we can plan the migration. Then another thing is that if we want any domain-specific knowledge information into the application, that can also be considered while partitioning our monolithic into microservices application. So once we have decided what will be apart, what will be used functionality, we are going to use in our microservices, then we can come into the next part, that is databases. Maybe we can firstly consider how if we are dividing our monolithic application into 2 to 3 applications. Suppose I'm having 3 applications. So currently, we're having only 1 database, then we can decide what are the databases we would require, what are the tables. And for if we are using 2 to 3 databases for each and every functionality, then maybe whatever functionality we are having, we can assign a single database to them. So, this is the second part. And the third part is that how these three services are going to communicate, or if any of the client request is going to come, they would require a response from 1 or 2 services or like all of these 3 services, then how we are going to aggregate that response and how it's going to interact. So this is the third part we need to understand. So, within that, we can use API gateways. So, API gateway pattern. Also, decomposed UI pattern. It means that if suppose those APIs are going to be used in any of the UI building activities, then rather than depending on the whole API or whole API response to create an entire UI, we can give whatever UI we wanted to create, that can be divided into subparts. And we can call the API responses or we can call the API accordingly so that if any of the services is going to fail, it won't break the entire UI or entire functionality of the client. And in API gateway, again, we can use the aggregator pattern so that if we require to combine responses from multiple services, then we can use the specific aggregator service, which will be responsible for controlling all the requests.

Snippet. You can spot the issue that might prevent it from responding to the correct issue. To 10 points, then you'll see if it if you can respond to the issue that might prevent it from responding to HTTP request post mapping. Response entity, the address, first about item. Response entity dot okay. I think response entity dot okay is going to provide an issue with status, but we want response entity. So I think whatever returning types we are doing, that is totally incorrect. Post mapping. Yeah. This is what I think. Return type is like, incorrect.

The principle mentioned is the Single Responsibility Principle (SRP), SOLID principles, and the Dependency Inversion Principle (DIP) in object-oriented programming. Here is the corrected transcript text: An important principle of object-oriented programming is quality. Can you identify the principle and expand the variation? Okay, private. These are private methods, and these are the public method for setting. Width and height. Okay, overhead. Set vertical. I think I think dependency inversion functionality is lacking over here. In set width also, we are setting height. And during setting height also, we are setting a width. So dependency inversion principle is missing because if we wanted to set a bit, we should have a common functionality that we should initiate the build. And we haven't created. Fine. Interface Segregation, the kind of interface segregation, what we can do is, like, we should only implement the required functionality. Right? So this part is also missing over here. One is dependency inversion, another is interface segregation. It's kind of like it's not an interface, but according to the principle, it's saying that we should only implement required features or required functionality rather than complicating all implementation of functionality.

What are the techniques you would imply to streamline the processing of massive datasets using Spring and Hibernate while avoiding out-of-memory errors? Firstly, whenever we're going to handle massive data, we should filter it out correctly or whatever input we're getting from the client, so that we don't need to fetch all the data which is not required and utilize our resources unnecessarily. So this is the first thing. And the second thing is that, whenever we're responding to the client, and it's a huge data, then we should provide it with a pagination format so that if a lot of data is coming, the system won't crash. They would be able to handle that in page by page manner and appropriately without consuming a lot of data. They can handle the less amount of all the data but in the required format. Okay. The third thing is that we should avoid N+1 related issues. It means that if your dataset has a new set of children related to their parents, suppose I'm having a student database with student data and it will contain course-related details, its fees-related details, and all. So if we're requesting all student data, then that response doesn't require what the fees students have paid, whatever the course students have taken. Right? So only it should contain the student data but maybe it can include references of fees and the courses so that if it's required, then they can externally fetch those records and it will not create heavy objects while retrieving all the student records. So this way, we can avoid and then streamline the processing. Okay. What else we can do is, like, I think connection pools within the database are also required, because creating a connection pool for every request will be a very non-cost-effective way. So, maybe AWS RDS is providing a good mechanism for using a connection tool. Similarly, we can use these mechanisms and serve the resources. After that, caching is also important. So if data is huge or if we're aware about if a similar kind of request is occurring repeatedly, then we can use caching. We can save that whatever response.

Would the use of reactive programming in Spring Boot be advantages compared to traditional blocking methods? Reactive programming I'm not sure about reactive programming, but it's kind of like Lambda, and all. So what I really feel is, if you're creating huge UIs or you're creating big APIs, then in that case, or we're creating views which capture all the data, but you want to show only a small amount of data in the UI or to the client, then in that case, we can use lambda expressions. So, lambda expressions. Within that, if a user is going to call a specific functionality, then only we operate on functions. Suppose I'm having a user screen, and we're using it for a supposed student record screen, and we're having multiple tabs, like the first screen is user details. The second tab is their fees details. The third tab will be their courses details. So, whenever we're fetching records, we don't need to implement all the functionality of all the tabs at one time. What we can do is that whenever a user selects the second tab, which is related to course letter details, once that's been clicked, we can load the data required for that tab. Right? Rather than creating it on a prior basis. And similarly, we can apply the same logic to other tabs as well. So, in that case, I think blocking will be handled.

If tasked with improving test decoder for Springwood project, how would you go about prioritizing the test cases for the critical areas? Critical areas. Firstly, if it is in critical areas, then I will try to create integration test cases so that within the integration test cases, we cover entire scenarios together. So within the integration test, we can create test containers which can directly mock the exact behavior the user is going to perform with that specific functionality. So that with the integration testing, we are covered the entire flow. Then I will consider the unit testing part. And the second thing is that maybe we can cover negative scenarios into integration test cases. And if you require a complete end-to-end flow, that is from user UI to interact with multiple services and then getting response to the specific UI and all. So that can be handled into automation regression via Cucumber or other frameworks too. So, I think all negative and functionality-related testing should be done into integration. And once that is done, we can consider the integration test cases flow. Then we can consider unit testing flow, and then in the last, I will consider the automation integration.