Avijit mitra

Hi. My name is Abhijit Mitra, and I have around 9.6 years of experience in Java and Data Technologies, including Spring Boot and Microservices. And I also have knowledge on Hibernate. That is the ORM tool that I use in order to connect to the database. And the architecture that I'm following currently, I have probably been following the architecture of microservices since 2019. So it's been like 5 years that I've been working on it. Apart from that, I have knowledge on certain AWS resources like AWS SQS and AWS S3 bucket. I have mainly used these two to dump the data and store it securely in the cloud. And the message service that I use is Kafka. So Kafka is a secured message service that I use for making service-to-service interaction asynchronous. And apart from that, I have knowledge on SQL, MySQL server, MySQL server 12, and MySQL database. And the NoSQL tool that I use is MongoDB, in order to maintain a large volume of data without making it structured, so that we can actually have a large amount of data in the cloud without maintaining any proper stable structure. Apart from that, I used Elasticsearch for extensive searching algorithms. So Elasticsearch, I use for those services which are majorly used for search, and not for updating. So that is one thing that I did as well. So, yeah, that's pretty much what we worked on. And currently, I've started using GraphQL, which was the requirement that came up later on because some of the services are actually used as a single service, which has a lot of attributes in the response. So based on certain criteria and the requirement of a single or specific service, they provide I mean, they ask for a certain attribute so that we can provide them that without making any changes in the code, without also introducing any new endpoint in the service itself. So, GraphQL is something that I have started working on recently. So, yeah, that's it.

So, spring batch is something that Spring already provides it. Like, there's a job launcher interface that we choose. The job launcher interface has certain jobs. And the job has certain steps. Those steps use certain processes, which are actually scheduled with certain cron expressions. A large volume of data, like exporting a report from a database, is a scenario where we actually use this job on a daily basis. Like, suppose Monday to Friday, we use a cron that is triggered Monday to Friday at a certain period of time in a specific time zone. So, that particular batch is actually run every day at a specific time and triggers an email with an export report to all the stakeholders of the particular application.

Yeah. So the Hibernate session factory is something that the persistent context. So we use basically Spring Data JPA in order to connect to the database. And the thing is, the Hibernate actually takes care of the session factories and all. So the ORM that you will use, that is Spring Data JPA, that implements a hybrid approach. So the session factory that we use for concurrent applications, where we actually provide all the information of the connections and all. We create a connection pool, and we try to make it as robust as possible, based on the application, for the amount of traffic the application has. So based on that, we create the pool because an unnecessary large pool can actually cause more resources, which are not actually optimized. So if we are engaging more resources to a specific resource, then probably there might be issues in allocating resources to other sections. So that's why the connection pool that we create in the hybrid and based on that, the session factory is created. So if the traffic is higher, then we can actually allocate more threads or allocate more sessions to a specific thread so that we don't end up losing threads and we don't exploit the threads which are in the queue. So that is one thing. And since we are using Spring Data JPA, so all the HQL queries that we write, which are highly optimized in order to provide certain solutions to certain criteria. And there is a good thing about this ORM, like we have a caching mechanism so that every time or whenever we are querying a data, if that data is not persisting in the cache, the hybrid persistent context. So if the context is not having the data, then it goes to the database so that we can minimize the data-based traffic from the application side. So, yeah, I mean, pulling the data from the persistent context is highly feasible in these case scenarios, like when we are dealing with a multithreading environment or a high volume of traffic from the users.

What is the best way to implement? Okay, so basically, in our application as well, we use a config service. So, a config service is something that we implement to make all configuration-related stuffs outside of the application. Like, we externalize the application property files so that any application can look up the config service based on their requirement and fetch it. They can fetch it directly from the config service, and we create the service. We use GitLab as a repository for merchant control. So, we have a particular specific repository for maintaining all the information within our property file. That property file is basically pulled into the config service. So, whenever an application or a service is trying to access a certain information that's part of the application property file, they can directly ask the config service, and the config service pulls the data from the repository and provides that data to the application. And another way we are doing it is that there are certain environment variables that can be passed from the values.yml file because we are using a Helm chart to maintain Kubernetes deployments. So, in the environments section from the values.yml file, we provide certain environment variables, which are specific to a particular service, which are not actually generic property files. So, that's how we do it in our application.

So, this distributed system follows the asset property, like so, I mean, if a system is connecting to a database and if the system is monolithic, in that case, the transactional boundaries are quite simple to maintain because all the interactions between components are actually within the same application. So when it comes to the distributed system, there are certain mechanisms that we follow. One of them is 2PC, which is 2 phase commit. What we do is, when a particular application is interacting with the database, it first gets the acknowledgment message. If the acknowledgment message is already provided, then only it goes for the commit. This is called the 2 phase commit when we get the acknowledgment first, and then we commit all the data. That is, if another application is waiting for a sign-up from the other application, in that case, what it does is, it checks whether the commit is done or not, then only it proceeds with its commit. So if the acknowledgment is not properly provided by the application or the commit is having some certain trouble, we entirely roll back all the transactions. So, suppose a service is calling through a REST API, another service, and it is waiting for its response. And that particular response, if that is used in another service's transaction, then it really helps because it waits for an acknowledgment or a commit message or a successful message. If there is any issue in the second part of the transaction, then what we do is, we completely roll back all the related transactions. If there are 3 or 4 consecutive transactions happening within the same request, then we actually roll back all the related or corresponding transactions that have already happened prior to the one that has some issues. So, that's how we follow. In microservices, this is the way, and there is another way that is the 3PC, but that is a bit complicated, so we don't go for that because that is something that needs a high amount of attention. So, yeah, that's what we don't follow. And apart from that, one architecture that we follow is Saga for microservices. Saga is an event-based transaction mechanism. It has two parts, like orchestration and choreography. We use orchestration. There is an orchestrator that actually takes a look into all the messages so that the next or corresponding transactions can be followed based on that.

Yeah, memory leak is something that actually, I mean, being a Java developer, the main benefit that we get out of Java is the garbage collection. So, garbage collection is something that we get by default from Java or the Java JVM. So, Spring Boot is based on Java. Spring Boot takes care of all the bean's life cycle. But the thing is, I mean, if the beans are created in a singleton scope, then I think, then it gets destroyed in the disposable bean section because a bean has a specific life cycle from the initializing bean to the disposable bean. So, if it is in the scope of Singleton, then the disposable bean takes care of it when the bean has done its work. So, the disposable bean actually gets called, and we have predestiny methods and all. So, we are called by default, and singleton beans are disposed or they are ready for garbage collection. But if the scope is prototype or request or any other which requires a continuous creation of instances of a particular bean. Right? So in that case, I don't think it's Spring who does the job for the garbage collections. In that case, we have to explicitly implement the disposable beans so that the beans, which are getting created, on each request, the instance needs to be nullified so that the instance can be taken care by the garbage collector. So we have to make sure it does not have any difference, so that, I mean, it does not go to the old generation or the survivor space of the memory. So, that's pretty much what Spring provides. But, yeah, I mean, Java takes care of it mostly. So, that's a good part for, as a Java developer.

So I find 2 issues here. See, the double lock is not there because if any thread checks at the point where the instance is null and the other thread actually checks it. So if 2 threads are checking it, there might be some ambiguity. I think the critical section that is if instance equals null should be in the synchronized section. Double checking of the instance null check of the instance would be beneficial for long term multithreading projects. The synchronization should be there, synchronized within the bracket. We should do the singleton class. The synchronize block we should write for the if condition under the gate thing gate instance method. And I find that public static singleton instance, the class variable has been declared. So I think it should be volatile because volatile makes that particular reference variable or member variable visible from the thread side, I mean, thread monitor side. Like so the value will be picked up by the thread from the heap memory, not from the cache because every thread has its own cache. So if it is looked up from the cache, then there might be some different data. I think it should be made volatile, that instance variable, so that every time this instance variable is read for the null check, it should be read from the heap space instead of the thread cache.

So, I mean, if we are extending it, then I don't think we should again call the super because this is a part of the concept. So if we are not making any changes in the overwritten method, then I don't think it is a good idea to actually implement it at all. Like, if we can just keep it simple, without implementing it, if there is no new implementation as part of the child class, then we can keep it that way, and we can keep it as it is because calling again the super is not recommended. The super is, I mean, that big tangent class has already done the same thing. So if there is any new implementation that we're looking for, then it's fine. But, otherwise, I don't think calling super is a good idea.

Okay. So, see, the spring boot is already something that we use for microservice applications. Right? So, we already follow the saga pattern, but in if we are talking about only Spring Boot, Spring Boot has certain fallback mechanisms that can be followed. So that can be actually implemented within Spring Boot. We have a certain library called Hystrix, which is maintained by Netflix. So, from that, we can actually get certain benefits of circuit breaking of particular requests. So when there is a failing response from a connecting service, we can retry the particular service for a certain time. So if the service is still not up, then we can provide some default response to that particular request, which is taken care of by Hystrix as part of the fallback mechanism. Apart from that, we can get some bulk hit pattern as well. Like, we can provide a certain section to a certain thread. We can limit certain thread pool for maintaining certain requests so that if any application is not responding, all the trades don't go to the same section and they wait in the queue and they don't down the particular system. So if a certain number of trades are already engaged in a particular section for a specific service, then there should not be any new thread allocated for that particular section of code. So this is how we can restrict some seamless failover. And in the case of event-driven architecture, in the event of a system crash, what we can follow are certain asynchronous processes as well. So if we are waiting for a certain response or certain data from another service, then it's always better to go for the pub/sub model. So, Kafka is something that we can use, so no trade is basically waiting for a longer period of time to get a certain amount of data. So it's always better to release the existing thread, and we can allow the new thread so that if going forward, the application is getting large and the requests are coming in a higher volume, then we can actually accommodate more threads. And apart from that, reactive programming is also something that we can come up with some solution with Java 17 version. So, basically, reactive programming is also something that does not wait and does not allow us to wait for a longer period of time. So that change in the mindset of adopting this reactive programming is also good.

I'm trying to learn currently how to transition a Spring Boot service to a non-blocking model using Reactor (not Red Blocks). So, basically, that's something I'm trying to learn because as Java developers, we mostly rely on the blocking part of the program. We usually wait for certain responses and based on that, we do certain activities. Right? So, I mean, but this non-blocking mechanism helps a lot in releasing the current rate and accommodating more threads into the application so that the application can be more fast and produce responses to the clients. So, the non-blocking using Project Reactor, I haven't actually used it as of now, but I can talk about the Computable and the CompletableFuture, which I used. Those are not actually completely non-blocking. They wait for certain things to be happened. But at least, if there are two duplicate services we are calling from our service, at least we can actually supply with the method reference. We can just get the response whenever it's ready, and we can do it for both of the service responses, then we can actually do the CompletableFuture.allOf when both responses are ready, and we can just combine them and produce it to the controller. But in that case, scenario as well, we use join. Right? So, async or join is also something that waits for a longer time. That is waiting for a certain period of time, which is not fully non-blocking. But yeah, the non-blocking section is like Mono. I heard about or I read about Mono, and Mono is something that does not wait for a particular object to be returned. So, this is something that we can use. So, yeah, non-blocking reactive programming is something that boosts the performance in terms of thread maintenance. So, more threads can be accommodated in a single application, and we can reduce the queue of thread waiting threads in the application as per the requests.

If the application is really large, and used by end users like some ecommerce sites, such as Amazon or Flipkart, which get a huge volume of traffic on a day-to-day basis. For these sites, I think adapting reactive programming is beneficial. This is because they can accommodate as many threads or requests as possible in the application, which is better for the user. It allows them to get a response without having to wait for a longer period of time. Thank you.