Vineet Kumar

Regarding the ORM, I have used normally mongoose with MongoDB. So, continuing about my experience, I started in 2020, and the last organization I was working with is called Get Card. It has basically two projects. One was an ecommerce type, and the second was Exon. My roles and responsibilities were to handle the back-end, make new functionalities, contribute to them, and add and optimize the code. Regarding the optimization method, I contributed towards upgrading the old code that was written on node 12 version to the 18th one. I contributed a lot in that. I also contributed to working with sockets used in the social media platform. I contributed to the video streaming part. That was about the last project that I worked for.

Regarding the circuit breaker pattern and its application, it depends on external integrations. First, we have to understand what the circuit breaker pattern is. The circuit breaker pattern is when you have a request and you redirect that request. Then, based on the implementation that comes after, you make changes according to the event. This means you particularly change certain things. It's like you can have your payment gateways correctly, and if you have your payment gateway attached in the pattern of a circuit breaker. Generally, what we can have is redirecting the payment coming from one source. If the payment has been cleared, then you can have events after that. If the payment has not been cleared, then you can break that particular request and send your response or do whatever you wanted to do with that request. This can be one example of an external integration. That's when, if your application has a payment-related thing, and it's making payments from any bank or any other third-party payment gateway. In that scenario, the circuit breaker pattern helps a lot.

So the most reliable method, basically, we can have is with zero downtime. Basically, what we can have is zero downtime. It's generally not a practical thing. You can have a very low downtime, so that is what the ECS can have. But, if your application has been hosted on ECS, I mean, elastic container services, so what you're gonna have is you can have the same APIs and everything. You can make a different container, and you can just stop the container which is in the network in which you're authorized. So what you can have is you just put a different container in place of the last container service that was running. It's like you have a container on staging. You can just go and put that staging container into the master with the same APIs and everything, and so the traffic will redirect to a different container, and that's it. You can just stop the load from one container and redirect the load to a different container.

Transactional integrity when working with a NoSQL database in a Node.js application is a bit tricky operation. You have to maintain the isolation level in the Node.js application when you are working with a NoSQL database. And generally, the isolation level that I'll generally have is that you can say isolation is generally eventual, which means you maintain the principles that eventually consider consistency and see and the durability of your data. So, what you can do is you can allow only one. It's like you can use Redis, and you can have your read locks out there so you can block the thread while you're working with it. So in that way, you can.

So describing about the diagnosis of memory leaks. Memory leaks is a very important part in Node.js. Sometimes you have many operations, like APIs going out of the memory. So you have multiple third-party modules, and what you can do is you can just have them and see which function is taking how much time, meaning how much memory and acquiring almost certainly like that. And while calling the API, you can have a link to the console. You can console in the browser, and you can directly see which API is taking a lot of memory and everything. You can have third-party modules which can track your API's heap consumption. And to conquer those, you can certainly increase the heap size too. But first, you have to see about your system design. You have to design about which object to use, which class is performing, and where you have to let it go. Instead of using maps, you can use weak maps wherever possible. So you have to write the code in that way. You have to free up the memory as soon as possible. You know, just freeing up the memory if it's not being used again. So the best scenario would be that you free up that particular memory.

So regarding the communication protocol, the best way is to use the HTTPS protocol, first of all. You have your proxies covered in a right way so that you have properly configured proxies. This is one method, and you always use the HTTPS method. Nowadays, if you make a different part of it, then you can use Protocol Buffers also in Node.js, so that makes your communication protocol very good using tokens and different systems as in the Port Particle inside the port. And while considering the AWS infrastructure, you have to take care of the IP addresses and which ports are open for what particular method. If there is an application deployed in a container or an EC2 instance, you should have your ports open only for that particular instance, and only that particular IP address should be allowed. No other services. So in that way, you can have your things configured properly.

So by looking at the code, I feel that it is a singleton pattern in which only one instance of that particular class has been maintained. And it is beneficial in the given context, so though the data doesn't change down the way. So only whenever we are providing the data, the data is not changing in the way. So the data remains the same and whenever we are using that particular data, it is generally remaining the same. There are many applications of this pattern, the singleton pattern. In those scenarios where data is really not changing, it's like either user profile. Like, whenever we are showing a particular user profile, the data remains the same. If that's been updated also, then we get it, and then the data remains the same. I think the singleton pattern has been used here.

So, basically, as I can understand about the question is, it's like we wanted to change the architecture from monolithic to microservices-based and API-first NodeJS application. So in these kinds of scenarios, we have to first understand which particular services are being used the most and least. We have to find the right services, then break them down. With the help of serverless architecture, such as Lambda services, we can propose or launch different instances for each service. That is, we can have a load balancer for each instance. After that, when it comes to the database, we have to disintegrate it into separate databases, collections, or tables based on which ones are most used, so we can implement sharding and other strategies. The strategy first is to identify which APIs are being used the most and which are used the least. Then, we bring it down to what services can be clubbed together to save resources. For example, payment resources can be combined with user profile information, as users generally don't access their profile often. We can then disintegrate them and club them together, appreciating both services the most.

So regarding the high availability and disaster recovery for the stateful components, so then a node says application on AWS. First of all, you should have your backup ready if it's on AWS. Secondly, if you need to ensure high availability, if you're going with instances, then you have to have your load balance configured so that you have high availability as soon as your load is high. You can then launch another instance, and their availability is there. Regarding the disaster recovery, you should have your ECS configured so that if one container goes down, another container automatically goes up with the same configurations and everything. That's one thing I can relate about. High availability is related to load balances. Load balances are necessary. Your load is balanced. And if you have a microservices-based architecture, then for each service, it should be done differently for different services.

So, basically, strategy would be employed to optimize query performance. So, different computing distributed computing services exist. So the query is mostly interacting with the database part. While you make the queries, the database is more employed up there. First, you have to understand the concept of indexing. Whatever indexing method is used, secondly, your database design employing asset principles matters a lot. When you have your schema configured, you have your database with standard principles. On the Node.js platform, getting your system in low-latency areas is key. It's like if you're setting up in India, then the Mumbai or Hyderabad region would be better. That's one thing. Secondly, whenever you're writing down the query, it's best to write the most effective query. It's best to optimize that particular solution. That's one thing.

So new ways to use the gators. You can use the data actions. You can use the bundler. You can always have your thing configured that particular workflow while anyone is deploying the code, the code chat means the bundle should be checked through the get actions. So that allows you to know if the code has been added, then the code will run or not if there's a problem or not. After that, there should be manual checks also. So