Kajori Sharma

I've been in this role of engineering manager for 4 years where my main responsibilities include managing the team, helping the team with technical decisions, keeping track of the project, taking regular sprint planning, maintaining the sprint backlog, and assigning tasks to the employees. I also set up the KPIs and goals for team members, measure the performance of the team, and focus on how I can design and help them in the design and technology selection process.

So, majorly, NoSQL databases are helpful when the data is not useful in a structured format, but more in a document format, and the properties may change very frequently for each element, like a document. So, one document can have name and address, and another document person identity can have name and other number or PIN number. So, that kind of data we change randomly is helpful in NoSQL databases, and an example is MongoDB.

WebSockets are majorly used for the connection between applications.

For micro service architecture, it's majorly helpful. When you have different functions, the functionalities are, like, functional responsibilities are segregated, and they can work individually instead of depending on each other or being tightly coupled with each other. So, suppose there is a processing model, and there is a model processing and research processing. Then these two can happen individually where the research documents are processed separately and then sent to a common database, along with the processed data. Also, there are model processing where the model documents are uploaded and those documents get processed separately with different business logic, and the processed data is then sent to a common database. We can then use data analytics or data analysis projects to have a look at that data.

So, for JavaScript, the best practice is to have high quality of production code. JavaScript should be lightweight. For ensuring high quality, first, whenever we're uploading the script to production, it should be minimized or compressed, which helps improve the speed of the code. Then, we can remove the comments from the JavaScript code, making it lightweight. As far as I remember, these two points are key.

A single page application is where all interactions happen within a single click. The request doesn't go to the server, only a single request goes to the server, and the rest of the page is not reloaded every time an event happens. That's what a single page application is. Earlier, we used to have a web browser page where for each request, it used to go and hit the server, bring the data, and then fetch the data, and then come back. In a single page application, we have multiple components, all connected to an API, or a backend, and once with one request, all the data can come.

To defect a monolithic application to microservices, we have to first find out the non-trivial, like, what we can ensure, like, what are the different functionalities or how we can divide the service, and we have to identify the different functional aspects of the application. And don't plan to, and then think of the 80-20 rule where we can see that only 20% of the work is done by 80% of the functionality. So we have to identify that 20% first. Maybe think of removing that from the monolithic application. Then we have to see all the integration points where the functionalities are overlapping. We have to separate out the database design for each microservice so that the databases are separate. And then we have to take the time. Then we have to do the impact analysis of how removing this functionality will affect the whole service and if it can work individually. So after doing that, we can take out each separate functionality, either serially or we can plan it across multiple projects.

We can have a state management in a ready's caching or in database. We can have this in cookies, we can also use sessions.

Considerations needed when designing a system that can handle the scaling of 1,000,000 concurrent WebSocket connections, if it is based on a load balancer for sure, where the load will get divided across servers. And then we have servers which can scale automatically like in some as in AWS where 1,000,000 concurrent web site connections.

No. Sorry. I have not worked on a detail like environment

In our company, we had a monolithic.net application where we had everything, like all the functionalities were together. So out of that, I have successfully extracted three functional areas from that monolithic application. One was the entitlement process where we give the client's rights and permission for different resources. We designed a UI from scratch in React for the front end and Python for the back end, with multiple APIs. So that was one functionality which we have extracted. Then the other was a research application, which we extracted from the monolithic application. The research documents were earlier pushed to an SFTP channel and were getting processed using different functional business rules. We then moved that to AWS, where new clients were uploading documents, and also migrated old documents from SFTP to AWS. A few clients were pushing it to SFTP. We have another function to push those documents from SFTP to AWS and then process the documents in the back end.