Lallan Kumar

Basically, I'm using an asset property in MongoDB. It's not inbuilt. I will make one by using a fallback in my application. Thank you.

Before moving on to production, create a different environment where the architecture will be moved into microservices using different services, like database management, how the fallback will manage if any transaction occurs, and how the API will increase speed by using Redis or other caching mechanisms. Once all things are completed, go for a QA approval. After that, all can be pushed to production without deleting or affecting any data.

For high availability, Namo, we can use a scalable application. Like, EKS, we can use here, where if the number of users exceeds what we've defined, then the application would be auto-scaled. We can also use throttling so that if a user gets an API response and tries to call again and again like a hacker, that can be blocked as well.

In a heavy read and write loads, we can use cluster as well as auto scaling, and we can use queue management where we can write the application. We can use a different write technique, and we can also use read as well. Like MongoDB clusters, we can use. And replica, we can use, where read has a different port and write has a different port. Because read operations have a higher latency, we are using read approaches. And somehow, we can also use write operations. So we need to consider latency in data, but the right approach, we can use a queue as well.

What are the key features in there? In microservice architecture, we can use to share data between services. We can use gRPC for real-time data from different services. And if we want data like a transaction, we can use transactions. At that time, we can use a queue management like Kafka or RabbitMQ, where after a transaction, we can give the response with using socket. We can use different databases for each service, and we can also use Redis for instant response, like the profile API would use multiple times. So we can try the profile API in Redis. Once everything is updated on the user side, Redis also gets updated. And we need to write code there. The reader application will work differently and the writer application will work differently. So that all load will not go to the same port, right, like a replica. We can use this.

We'll just update the status code 500 to 400 because 500 will throw a server error, internal server error. We need to change from 500 to 400 in cache. And we need to add more things like if the user has authenticated, we need to add logic for additional authentication lock in here.

Connection pooling. In connection pooling, if we need to create a connection pool because if we do not implement connection pooling, we do not manage the connections efficiently. The connection is started, and after the process is completed, the load on the connection will be broken. At that time, it may cause some errors, so we need to write maximum connection pooling in a particular instance to prevent any unwanted users from attacking that instance.

Steps. We need to add a gRPC for inter-server service communication. Basically, gRPC will transfer data within components in the form of a buffer. That will not be easily readable when data is communicated within the server. And, we need to check if we are using a different server or instance. We just need to add the application on the server side. Only then will it be called when the server calls from the particular API. Otherwise, it will not respond. It will throw an error. So, that will also secure the microservice architecture as well.

We need to work with MongoDB, we need to implement a master slave method. Basically, in this method, if any master or slave is not working, the other slave automatically takes over as a master and shifts the control to that. In master control, all things work as they can handle read and write operations and execute. But in slave, they can only read. We can use the master slave protocol, or master slave method.

We can create a replica for that time. When we are interacting with the AWS, we can create replicas. That's why if one replica is not working, others will automatically work. So that's the good practice for that.