Siranjeevi Rajendran

I, uh, so I didn't see that the recording has already been started. So, uh, like, the person on the other side, hi. So this is a very new experience for me to give a a recorded video interview. But, yeah, the question is could you help me understand more about your by giving a brief introduction? See, I I am, uh, Siranjeev, so I have close to 12 years of experience in this industry. I worked in a start up to, like, corporate mix stuff. All the experience I have. I worked in very small start up with a bigger corporate like Samsung, you know, Athenahealth. Right? So majority of my work was, like, in the back end. So as a back end engineer and lead, currently, I have, like, 12 years of experience into Java, microservices, architecting things, you know, leading the team. Right? So it's it's a mix of experience. So if you ask me, I would have done, like, almost, uh, 20 to 30 percentage into team leading, and then the remaining 60 to 70 percentage, I spend time on code reviews, my own coding, you know, design reviews, design discussions, and all those things. Right? The remaining 20, 30 person is going into, you know, organizing things, working on the deliverables, schedules, planning, retrospective. I mean, as part of scrum, you have to go through and get the things moving as a lead. Right? Of course, back by sessions, you know, sessions to fix the bug, technical debts, all those things. Yeah? That's pretty much a little bit of brief about my background. Okay? Thank you.

So, uh, what strategy would you utilize in Java to implement the microservice? Circuit breaker for the fault problems? Okay. See, the moment when there is some issue happening in one of the microservices or one particular microservice is not responding correctly, the the immediate thing is we will go for see, again, it is very much dependent on the use case. Okay? Let's say if there is a use case where you have some default, you know, response, right, you can immediately, you know, fall back to that mechanism of taking default response, and then you can go for, uh, retrace. Right? Again, retrace can be done without the real API. So we would go for we we keep we open the circuit so that, you know, the further furthermore any downstream system will not call that particular API until the API becomes healthy. Right? So the circuit will still be open. So that's the basic idea what we do, right, as part of this. And then and then, uh, see, uh, coming back to the retrain mechanism, we may go for, you know, exponential retrace with some bit of jitter, like, jitter used for, like, some randomness so that we we can go for retrace after, you know, the things become healthy. Right? So there are a number of reasons why certain service might go down. Right? So in such scenarios, we should be patient enough to, like, not overload the system much with too many bombarding retries. So that's also one key thing that I have done. And introducing queues in between also could solve the issue, like and, again, it comes with the latency. Right? So if you want a really low latency system, then you have to fix the things on the go and in in, uh, during the during the synchronized call. Okay?

So the interservice communication. Right? So if you ask me, I would propose I mean, I have done more of, you know, uh, CQRS kind of thing, like, more like an Kafka in between, and then you can make into service communication. That is one way. Right? So that is one way that you can, if at all your system isn't I mean, if all the interservices are lying in your own environment, then that is one way. Our the standard way I would propose is the rest API. Right? So rest API with what, 2 dot or some other, you know, secured mechanism wherein you do the token exchange and then give, um, certain permissions to access certain APIs. Right? So that is one way you can securely, you know, make into service communication. So, for example, sharing an auth token or JWT, right, Java tokens, and then that can be used by the other party, and we'll have some auth servers to validate the API communication, which happens every time before allowing somebody into that. In general, we can have an API gateway which can handle all these, um, security issues, issuing security tokens, you know, validating the tokens, allowing the people inside the service. Right? So I'm serving them into service communication can be done with the help of API gateway. That's a very, very standard way of doing it.

See, uh, again, see, between Java and Python, you would say. Right? So, for example, I had done the entire communication system, communication platform majorly on Java. Right? So it was entirely written on Java. And some bits of some bits of informations where I used Python in one of the Lambda, right, AWS Lambda, for getting the reports from the vendors. Right? So, yeah, I have written some of the callbacks using Python. Right? So that was running in a Lambda, which would be calling which we would call, like, at random times in random as in, like, at fixed intervals. And then that instances has I mean, why I went to Lambda because of you know, it doesn't have to be running all the time. Right? So maybe in an hour, it will come up for, like, 5 minutes, and then it does the job, and then it can go back to idle state. So that's why we chose Lambda, and that it's it's more for collecting the reports, delivery reports of the SMS, emails, push notifications for that communication platform. So there are, like, bunch of different use cases, I would say. Like, uh, I mean, in my opinion, Java is more for enterprise applications, heavy loads, you know, uh, and it has lot of open source library support, integration with, um, you know, Mongo, Kafka. Like, any tool is easy. Right? Easy. And, also, you can you can implement a lot of concept, you know, microservice architecture, microservice architecture styles. A lot of things you can do. Python, I still believe, like, it is not really for a big enterprise, and it's very good. You can write the code pretty fast and especially if there is something like a script kind of situation where so I I worked in a in a project where we did a CDC pipeline, right, so change data capture. Right? So, uh, wherein, like, when there is some database, was writing c we had a, um, Oracle database, which was the core for the entire system, right, entire company wherein already 10 tens and hundreds of thou thousands of tables were already there. People are already overloading with the query and request. For analytics purpose, we did not want to do any more query on that particular table because it's a relational table and already main business use cases are running and the analytical queries should not go there. So what we did was the moment something's happening, we started doing a CDC data pipelines, and then that was written in Python. Right? So, uh, some of the data listed functions and things like that, we have written in Python. Yeah.

Discuss methods to optimize Java microservices for performance in Spring Boot. Again, optimization comes with different perspective. So I I'm not very sure about this question. So maybe if there was an interviewer or somebody who could explain this better, that is easier to, you know, back and forth discuss and understand the context. Right? So from my understanding, so performance in sprint driven around I mean, performance as in, like, the latency or the number of requests are, you know, efficiency of this question, I'm not very clear. So I would leave it for the open discussion if we have the, uh, discussion directly with an interviewer.

See, the transaction management in a in an microservices environment. Right? So we can do a number of things. For example, we can go for a architecture pattern. So architecture style of saga. So saga, we can do choreography, uh, the other approach. Right? So we can introduce queues between multiple microservices. Let's say there is a microservice for sales, microservices for orders, and microservices for payments. Right? Let's say one sale is happening. So immediately, other service will will make an update like, okay, one order has been placed, and then let's say there will be a delivery service then. Right? So let's say in in that order I mean, in that, uh, you know, the in that series of API calls, like, when there is a sale happen, other API would be called, an order would be taken. And then from the other API, we will make an end. We will go for a payment API. And then from the payment API, once the payment is successful, then we'll go for the delivery API. Right? So there there is a continuity of, you know, distributed transactions happening across different multi different microservices. Right? Uh, during that such scenario, if something's failing, we might want to roll back. Right? So so so there are, like, 2, 3 different ways I have I I myself have tried. 1 is the 2 phase commit, and the other one is the saga button. Saga button is, like, the very standard approach, and it handles huge load, and you will have repay mechanisms properly done. And you make sure one consumer is reading the retrace and should not be all loading all the instances for the particular API. Okay?

So the major if you ask me, right, so the majority of issue with this particular code, like, the get instance method. Right? So we did not do the lazy initialization or, uh, the the early initialization where in the initial I mean, in private static singleton instance equal to new instance, could have solved the issue immediately, you know, instantiating as soon as the class is loaded into the memory. Right? Because it's a static, uh, variable. So by default, it would have been loaded. But the problem is we are trying to instantiate. Right, instantiate with, uh, when somebody calling, get instance method. So the possibility of 2 people or 2 threads calling the get instance method is very high, and we should never be, you know, giving away the the two instances as part of the design pattern of, you know, giving only one instance all the time. Right? So so the threads thread issue has happening in the if condition. Right? So once it bypasses the if condition, both threads can enter in the initialization of new singleton. Right? So the simple mechanism, I would say, is we can make a synchronized block. Okay? We can make a synchronized block inside the null. Right? Once the null is there, okay, instance equal equal to null, then you go into creating the new singleton in a synchronized block. Okay? So, again, inside synchronized block, we may have to check one more time instances equal to equal to null so that, you know, we have we we eliminate that situation where, you know, both, uh, went inside the synchronized block, and then after that, both did not check the instance equal to equal to null condition, then both can still create in an in a in an order of 2 different instances of singleton. So that's not allowed. So I propose, like, yeah, instance critical to null, and then you open a synchronize block. Then again, inside that, you do one more instance null check before in before, you know, initializing the singleton instance.

So examine the following code that is intended to lazily initialize an instance of a service. Can you explain what is wrong with this code and what could happen if multiple threads try to access the get service instance method. Okay? Okay. Service instance. Get service instance. Yeah. It's it's a same singleton problem. Right? So when when multiple threads try to get service instance, what happens? The the same thing which I explained in the previous question. So it's a multithreading problem which can happen inside this if loop. Let's say both the threads went inside the if loop, but at the same time, then the chances are, like, you know, both threads will create a new new service instance, and then it's it fails the purpose of singleton. Right? Files the purpose of service equal to null condition check. Okay. So there is a way okay. You can do a synchronized block outside if loop, but that will slow down every single, you know, requests, and that will create a bottleneck. So I would suggest, like, okay. After if condition, you you put a synchronized block. Make sure you, again, do a null check, and then allow creating a new service. Right? Let's say 2 threads are coming, and the moment synchronize block is there, it will acquire a lock, and then it will not allow any other threads access that synchronized block. Okay. After that, let's say t 1, t 2 is coming. T 2, both are coming at same time. Somehow t 2 got a fast access, then t 2 will enter into the synchronize block, and it checks still checks for the service null condition. Okay. It is still null, so it will go and create a new instance of service, and then it returns. And the next next comes the t one. Now t one t one came inside the null check, but since we have introduced one more null check, here, the service is not null. So it will not go inside creating a new service instance. Rather, it returns from, uh, that if loop and then I mean, breaks from that if loop, and then it returns the service instance.

Develop a comprehensive backup strategy for microservices. That spans multiple data stores. So develop a comprehensive backup strategy for a microservice ecosystem that spans multiple data source. So this is an interview question. Okay. This is more like across multiple data store. Okay. It was really a very hard question. I I can see that difficulty in the it sounds what it is. Many times, it it becomes very complicated, um, to understand the question with this type of video interview. It's still I'm trying to figure out. So comprehensive backup strategy, backup as in, like, taking backups of multiple data stores or backup strategy, comprehensive backup strategy. I'm not very much clear on this part. But this is a very interesting way of interviewing, like, recording the video and then So let me read the question again. So develop a comprehensive backup strategy for a microservice ecosystem that spans multiple data source. Expands multiple data stores. Okay. So I I I remember I have worked also in multiple data stores kind of systems. Right? So for example, like, no SQL SQL. Right? So these kind of different data stores is definitely there, and then and then taking a backup, right, with multiple data stores is very, uh, important because, again so let's say one data store goes down, the backup strategy must ensure, you know, the can consistency of data in the other data stores as well. Right? So the data consistency is, like, ensuring that the data from different microservices remains consistent during the backup backup phase. Like so let's say different microservices is writing the data on different service different data stores. So taking backup, you have to make sure, you know, you loosen that thread very carefully. That is 1. And then we should be, like, for each data sources, there will be, like, multiple I mean, different backup needs and then solutions. And then with respect to the automated and scheduled backups, we see we did, uh, we had Amazon RDS, and then it it does its own automated and scheduled backups. And then retention policy is, like, very, very important. And then centralized backup orchestration, like, uh, AWS backup could be 1, and then application level consistency. Right? And then