Samir Saurabh

Hi, y'all. So this is Sameer Saram. Uh, completed my MCA, uh, from CGNI University, Chennai in 2009, uh, and I started my career as a back end Java developer. And, uh, uh, I have overall around 14.5 years of experience currently, uh, mostly into Java and its related, uh, technology, like Java, microservices, RESTful API, web services, uh, then, uh, cloud, AWS, Azure, both then, uh, Hibernate, Spring, SQL, NoSQL DB, uh, then, uh, you can say, uh, messaging, uh, queue like Kafka, RabbitMQ, then a container service, uh, like a Kubernetes, Docker. So yeah. And as well as I have different domain experience, like working in a banking, ecommerce, uh, companies, and health care. And currently, I'm associated with, uh, a PMMDM, uh, domain, uh, company called Zendigo, working as a associate architect. And here, uh, mostly my, uh, technology is, like, uh, similar back end technology, like, uh, Java, uh, Apache, STROM, uh, you can say microservices, Azure, uh, mostly we use here as a cloud, Kafka, uh, streaming. We have, uh, and then, uh, Docker, Kubernetes as part of that for my monitoring, IOGL case tag, and, uh, Akivana, Permotias, Grafana, uh, for, like, log logging and monitoring, uh, this thing. And, yeah, apart from that, like, I do have, uh, exposure to some UI from 10 technology like React. And, uh, yeah, I I sometimes I have also worked in a mobile application development. Yeah. That's it from my end. Thank you.

Okay. Uh, so Okay. So, uh, here if, uh, there's a 2 microservices, uh, we have, uh, which is trying to modify the shared resources or, like, say, uh, shared database. So, uh, there, uh, like, there are 2, uh, 2, 3 things we can do here. The first approach, like, generally, we follow, like, uh, to have a single separate service for each of the microservices. But let's say, uh, uh, for this situation, if we have a a common DB or common resources that is getting modified by both of the services. So here, uh, we can take a, um, a kind of, uh, optimistic locking. Okay. So the locking, uh, mechanic, uh, we have, like, uh, either we can do optimistic, uh, locking or distributed locking, um, machinery over here. So I will tell that optimistic locking. So this will be up, uh, uh, like, locking technique where you will have the, let's say, a time stamp and version, uh, of the record, uh, where like, once you, uh, go and try to, uh, take the record from the DB, you your process will read that, let's say, uh, that version, okay, that is associated with that row. And, like, uh, while, uh, uh, committing the after changing while committing, it will check that whether that record is having the same, uh, version. Okay? If there is a change in version, that it will, like, uh, correlate that the records has been modified by some other process. Okay? So that will, uh, like, um, not, um, process it. Okay? Apart from that, like, distributed locking, uh, we can take any external locking through, uh, uh, Redis or any other, uh, locking mechanic to lock, uh, the sent sent light lock. Also, like, uh, setting up that, uh, no DB level isolation level, that can also help us to, um, take the log of that, uh, DB row. Uh, and, uh, if if any process like going and modifying, uh, other process had to wait until unless the lock has been released by the first process. So, yeah, 2, 3 ways are there to control that, um, uh, Spring Boot microservice if they are trying to, uh, access the shared resources.

Okay. So the best way to implement a global thread safe configuration accessible by all the components in the Spring Boot. So, generally, we use, uh, configuration, uh, service, which is, uh, outside of our application so that it per environment. Okay. So let's say I have, let's say, developer environment. I have, um, QA environment, and let's say I have prod environment. Okay. 3 environment. So whatever the configuration that we, uh, are, uh, giving, so configurations would be based, uh, on our environment. Okay. So each environment might be, like, dev environment. We will have the different configuration. Uh, QA environment, we will have the different configuration. And production definitely, like, it will have the different, uh, configuration. Okay? So runtime when the application is, uh, let's say, getting deployed and is running, it will fetch the configuration from that config, um, uh, files. Okay. And that in our application, like, say let's say you have the tenant configure or pod config that you can say, Based on your configuration, you can let that or you can say the dev config or QA config or prod config. Okay? So those files, like, uh, with the spring configuration, we can give that per environment, that file, and run time, uh, that our application will fetch the configuration and, uh, work accordingly.

Okay. So, uh, Memorial Legal, that major issue, issue, I can say, for our application. So, uh, generally, uh, before, uh, committing the code or you can say, uh, in our application, if, like, uh, memory not managed properly or object we are creating that is a kind of not, uh, getting, uh, claimed back by our garbage collector. So definitely, there will be a a memory leak. Okay? So here, like, uh, the question is, uh, to suggest the solution to reduce the memory leak in a long, uh, running Java, uh, Spring Boot application. Okay. So here, I can say, uh, based on your application, uh, no size or behavior, we can choose the different garbage collection, uh, algorithm that we have, okay, currently. So, currently, like, either, uh, generally, uh, nowadays, all our garbage collector works on, like, the firm gen, like, a new gen or old gen, um, space that we have in our memory. Okay. So that the garbage collector algorithms also work on that, um, how we are cleaning our allocated memory from that old, you can say, old old generation to the newer generation, how they are moving. So this newer generation will be, like, a new, um, memory location. And once, like, it is becoming the old, it is moving to the old gen x space. Okay? So choosing the garbage collection here important. Like, uh, now we're and then nowadays, like, we have g one GC or Jet GC, um, algorithms, uh, which you can configure, uh, or choose that garbage collector, which will not disturb your application. If you have that applicate schedule application, you do not need any downtime, um, for that one. So you can, uh, use that, uh, garbage collector. That is the one solution. The next solution I can say that, uh, any memory leak that if you, uh, have, then use some tool. Like, uh, like, we have a New Relic, uh, or JMeter. So just to test your performance, that will tell you that what was your memory before running the your application and what is the memory after running that application. Okay. So that, uh, with the help of that tool, we can, uh, detect that memory leak. If there is a memory leak, it will say that, okay, which of the modules, uh, from, uh, your code will have that memory leak. Then, like, our as a developer, we can go and then and analyze that code. Okay? So that piece of code, where is that memorial leak happening? So, uh, if you see that, okay, some resources, if we are allocating and not releasing that one, So that kind of, um, no best practices we can, uh, adopt over there or modify that code. But, uh, I and on top of that, we can choose the best garbage, uh, collector algorithm that fits onto, uh, like, our situation.

Okay. So what method would you recommend for securing restful endpoints in a Spring Boot application? Okay. So, uh, generally, restful, uh, endpoints are like, um, restful nature is stateless. Okay? So securing the, uh, you can say application is also, uh, we have to think something, uh, which will work stateless. Like, if you see that maintaining a session or, like, user authentication through the session, uh, that might not work in a async environment. Okay? So the server said, which is running asynchronous, that your, uh, like, token violation or, let's say, session, uh, through session or package tracking that might not work, or you will not be able to scale your application. Okay. So for restful endpoints, we are going for the stateless, um, you can say authentication, which is recommended now, like, popular technology that I have used is what add to or what and, uh, JWT token. Okay? So, uh, by this, uh, OAuth and JWT token, what that client will do, it will generate some token with the help of some secret key. Okay. And then it will attach along with the request, and that will be sent to the server. Or let's say your microservice endpoint, There, that your service will get that, um, uh, token from the client, okay, now and then request payload body, uh, header, everything so that your servers server end will have the some public key. Okay. So along with your public key, you will generate the, like, token based on that, um, that payload, whatever the URL and, um, with public key, it will generate the test signature. Okay? If the signature is matching whatever the request coming from the client, if it's matching, then you can say that, okay, there is no URL temp tampering has happened or your API was accessed by the only granted set of, um, clients. K. So you can forward your request to your controller further. So the best way to use this, uh, technique, uh, OAuth and JWT token, uh, for stateless authentication.

Okay. So next question is let what step would you would take to refactor a monolith Java application into a Spring Boot microservice architecture? Okay. So the mostly, uh, we have to take some, uh, thing, like, generally, I have done is, like, dormant driven design. Uh, it's a very popular, uh, you can say, uh, way of breaking that monolith into, uh, microservice architecture. Okay. So, uh, let's say, take one example. Let's say mono so domain driven, like, you have to identify the domain. Okay. Let's say I have 1, um, uh, ecommerce company. Let's say that I I am moving it to the microservice architecture. So the domain is something you can say that, um, order processing domain. K? So that order processing, let's say, uh, so that that let's say, uh, if you have the order or, like, payment, this thing you can identify your, uh, domain. And within the domain, there is some bounded context. Okay. So the bounded context is, like, uh, let's say, um, maintaining that, uh, product catalog or order or, let's say, user base. So this all the things you can convert into a microservice. Okay. So that's why, like, the the main idea about that microservice is, like, to, uh, develop a service independent, like, single responsibility. Like, here, you can think of a solid principle, okay, that, uh, we do. So each microservice is, like, uh, handle a single responsibility. Okay? So let's say, uh, user man a user, uh, uh, managed service we have or let's say, order service we have or product catalog service. So each service will be, like, uh, this service will be within that particular domain, and these are you can consider as a bounded context. Okay. So this bounded context, uh, we can implement as a service. And now on top of that, like, the second thing is, like, how to communicate. Okay. This, uh, definitely, this bounded bounded context will have to communicate with each other. So here communication, we we can do 2 types, like, uh, sync and async communication. For sync communication, like, um, you can use any rest template by calling that one service to another service if required, k, or, uh, gRPC, um, uh, that you can use to call that different service directly, okay, through their endpoint. But let's say for high, uh, scalability, we are choosing to have a async communication through that message broker. Okay. So let's say we have introduced and we are introducing a message broker like, uh, RabbitMQ or Kafka. Uh, that, uh, that will be used to communicate between these services. So those, uh, will be the after that, you have to consider that any distributed, uh, no, locking if that is required or, uh, say, request tracking, uh, from each to end, uh, one service to another service. Here, we can use that, uh, some of the our existing design patterns like, uh, saga or CQRS. That kind of design patterns for microservices, uh, we can use. Apart from that, like, um, uh, DV also that you can think of. Like, uh, here, uh, you can implement, um, DV for each services. Okay. So that will be independently managed and, uh, deployed. Okay. And, uh, yeah, definitely for monitoring and logging, we can use either ELK Stack or any, um, logging or monitoring marketing that

Okay. In light, the below code snippet, can you find what might be the potential issue with this singleton implementation in Java when it comes to multithreading environment? Okay. So singleton, basically, class where, uh, you can say that single instance of that your class will be maintained throughout that application. And whenever, uh, any requirement will happen, that instance only will be served through the, uh, your application. Let's say, for example, like, uh, logging. Okay. So we are one, uh, logger class, and that logger instance only will be used to log, um, uh, no, um, different logging throughout the application. So that that's the that's the example, singleton. So here, I can say, uh, for making the singleton class, like, private static singleton instance. Uh, so here, I've taken one instance of this singleton class. Now private constructor is there. Okay? Uh, so it will not be visible. Now we have one public, uh, static singleton get instance. And here, uh, if we are checking instance is equal to is equal to null, then we are creating the new, uh, single instance. Okay. And then returning the instance. So here I can see that, uh, for the multithreaded environment, let's say we are not, uh, here taking the lock of that, uh, no, instance creation. Okay. So, uh, for the multithread environment, it is mandatory to have, uh, no, locking, uh, mechanic. So one thread, let's say, coming and creating the instance. And by that time, other thread, uh, will also come and, uh, check that, okay, instance is null. It will also create that that, uh, instance of your class. Okay. So here, it is mandatory for you to, uh, create, uh, or take a lock of that instance before lock of the class before you are creating the new, um, instance. Okay. So the modification here I can suggest is you just implement that, uh, double check, uh, locking mechanic and, uh, lock that, uh, singleton dot class, synchronize singleton dot class, then you can, uh, inside that, uh, locking, you can check again that if instance is null, still null, then only you can create that one. Otherwise, you can just close then and return the instance. Okay. So here, modification is that inside this first if instance is called null, check that. Okay. Now check the log, synchronize, um, singleton dot class or this. Okay. And then you can check again if instance is called is equal to null, still after taking the taking the lock, then you can, uh, create the instance and return that instance. Otherwise, whatever the existing instance, you can return. Okay. So here, uh, for multithreaded, we can implement the double check locking. Thank you.

Okay. Given given Java Spring endpoint handler snipped, can you spot the issue that might prevent it from responding to the correct HTTP request? Okay. So here I can say post mapping, create item, create item. Okay. Generally, we'll not do like this, create item. Like, we are using the nouns, and this create will be like HTTP, uh, no, uh, my post, my get kind of thing. So API endpoint looks little weird over here. Now the thing is response entity, create item. Okay. Request body, we are taking the item then response entity dot okay then build. Okay. So okay. What is the thing? Twin point and let's see. Spot any so that might prevent it from this point. Okay. So this a int response entity that, uh, we are building might be some logic here. But here I can say, uh, request body, uh, that is coming. We should, uh, use that request body, and then, uh, we should process. Another modification I can say that, uh, if you if it's that, let's say, create item, you just take it in point as a item over here and, um, do a post request and send that uh, item body. Okay. And it will, uh, create that item based on that. Okay. So no need to, uh, give that API like a create item over here. And then once you are receiving that item, uh, that, um, POJO class or a request body, that you can process it and, um, go to your, uh, other layers. Like, if you have business layers or your DOL layer over here and persist that item, then you can, um, respond to this method and return to the caller. Okay? So those things, uh, you have to do over here inside this, uh, body.

Okay. What technique would you employ to streamline the processing of massive dataset using a spring and hibernate while avoiding out of memory errors. Okay? Okay. So to handle that, uh, mostly, like, streaming, uh, processing massive dataset, I would recommend to use, like, any bulk data or something. Uh, use dashpring batch instead of, like, a simple, uh, you can say, application. So, uh, if your data is really huge, that that Spring batch will help you to, uh, now clear the batch of the data and process it. With the Java 21, you can say, we can use also the virtual thread over here because, like, if you have the, um, a stream of processing a massive dataset. Okay. So this virtual thread, uh, we can use over here, um, to process our request, okay, within that screen. And that to update, like, let's say, I'm using over here as a ORM to save my request or do any, uh, database operations. Okay. So, uh, for each of the request, we can, uh, no, create one virtual thread and give the task to that. K? So the Java Java 21, we can create as much as virtual thread as needed for, uh, you can say, operations, and that will be done. And that will be, like, kind of non blocking. Okay? And it had no, maybe, uh, like, uh, like, uh, little background I would like to give it. Like, virtual thread is nothing but a newer way of creating the thread, which do not have, uh, impact on the on the OS. Okay? So, like, with the little memory, uh, also, okay, we can create that virtual thread, and it is non blocking, uh, thing. Okay? So, uh, that, um, your runtime environment will suspend that virtual thread until unless it is getting the callback. So it will not have the overhead also on the OS. So for streaming of the massive datasets, uh, we can use that newer, uh, framework that available with the virtual thread. And, yeah, definitely, it will not go out of the memory error because, like, we are not using that memory at all, uh, here, uh, like, uh, in compare of the older threads. Like, in older threads, uh, we had to, uh, know that, uh, that is the platform thread or let's say OS thread. So as much as you, uh, the thread you are you were creating, so that, uh, thread has the direct impact on your OS, and it is taking that, uh, your OS resources. Okay? But this new virtual threads are, uh, based on that, your JVM. Okay. So their life cycle will be managed by the JVM, and it is not the, um, no, heavy, um, resource utilized, uh, threads. So it is, uh, very less in memory, and, also, it's non blocking. So, uh, I would suggest to use that one, uh, virtual threading, uh, uh, with that newer technology. If you if you are not migrated to Java 21 or something, uh, use the string batch or batch processing for any massive dataset.

Okay. If you ask to, uh, improve test coverage for the springboard project, how would you go about per prioritizing test cases for critical area? Okay. So, yeah, we can use some, uh, framework definitely to, um, know, uh, like, uh, give the code coverage, uh, like our Cucumber or Jacobo, uh, some some of the framework or even the sonar, um, cube that we can use to check that, uh, which are the our critical, uh, or per module or let's say per, uh, services, what is our core coverage? Okay. So, uh, like, the code coverage definitely, uh, based on your organization, like, how much, uh, like, uh, your organization is towards that, uh, percentage looking for code coverage. But in general, like, we would like to go for, uh, 70% and above for all our our for classes and models. Okay? So, uh, I would suggest to use that, uh, some of the tools and see where that your code coverage is lacking. So it is mandatory to like, not mandatory or you can say that at least that critical area or let's say, uh, critical functionality or your application, definitely, you should write the test classes, uh, so that, like, no. Uh, any changes into future, uh, if you are, like, QA is running regression or even if we're deploying or doing some changes. So any change or any, uh, no, code break, uh, that will be detect, um, uh, in future, or it will help you to detect that any code issue in future if somebody is going and modifying that code. Okay. So definitely for critical section, we should write that test cases. And, uh, and we should, uh, at least cover the critical sections of our project so that, like, our application will not go for the task or any, you know, breaking the existing functionality if user is, uh, adding any new module or new feature. So you should not break the existing one. So, definitely, we should cover that. Uh, we should cover more than 70%, but at least if you are not, uh, managing that one, at least critical area, definitely, we should prioritize and, uh, do the test test coverage for that.

What tech is, uh, would you suggest for ensuring the integrity of a Spring Boot microservice ecosystem communicating over a mix of synchronous and asynchronous channel channels. Okay? So, yeah, synchronous, uh, uh, channel generally, uh, if we are communicating, then, uh, we are using, uh, no, rest template or gRPC to, uh, service to service communication. Uh, like, one service is, uh, directly, uh, sync syncing, uh, calling the another service. So we can use that, uh, directly through the API calling so that, uh, through rest template or, um, just the RPC, we can do that, uh, for the sync sync request. Okay. So another communication that async communication, uh, that we can do through the message brokers. Okay. The message broker in between the services. Like, one service is done, uh, let's say, um, their, uh, job. So it can generate the event and put it into the message broker. Okay. Then next service will, uh, take the data from, uh, that message broker, and it can, uh, process that, um, uh, their part of the job. Let's say I have 2 services. One service will, uh, do some let's say I'm creating 1, uh, entity. Okay. So one service will create the entity, and it will, uh, after creation or persisting to our DB, it is generating the event and putting it to, uh, let's say, message broker. Uh, let's say, I'm taking a Kafka. K? So it it will put that, uh, thing into Kafka. Okay? And from Kafka, let's say, our next service let's say, validation service. Okay? So it will, uh, fetch, uh, the things from Kafka, and it will process that event. Okay. So that event, uh, like, it will be, like, processed, like, their own thing. Like, since this is the validation service, it will validate that, um, persisted data, and, uh, it will again further it can generate the event and forward to the next service. Okay. So for async, we can go as a, um, message broker based communication. Thank you.