Jaimin Soni

K. So, myself, Jammin Sony. I'm coming from the IT background, and overall, I have around 10 plus years of experience in the IT industry. I mainly work with.NET.NET Core, and VC architecture. And from my roles and responsibilities, currently, as a lead in an architect role as well. Also, I'm familiar with the software development life cycle, and I hold a couple of certifications on Azure, such as the Azure Fundamentals (double 0) and Azure 305. I also need certification on top of that for my long-term goal, which is to become an architect. So, that's my oral background. And I also have experience on the Azure side for more than 5 to 6 years, using different Azure services like Azure DevOps, Logic Apps, app services, AKS, and Azure storage accounts, and many more.

So dependency injection, mainly used in.NET and also familiar in.NET Core, which provides inbuilt integration in the.NET framework as well as in the latest.NET version. The main purpose to use dependency injection is to create a loosely coupled code, and we can write test cases on each service layer for that. If we are using the decorator pattern, for example, we can write unit test cases on each service layer as well. When we do update it, whenever it's required, we can create a separate service based on our requirement, and we can inject it at any point whenever it's required. For example, we have two different applications. One is a web application, and another one is a mobile application or a web API project. Based on our requirement, we can create these services, and we can inject that service into a particular controller or base class. Right? So that loosely coupled structure, we can implement it with the help of the dependency injection. This will also help enterprise-level applications. Like, if we have any event-driven application or message publish or subscribe kind of mechanism. So in that case, we use this approach. It will be easy for developers to write code in a loosely coupled manner. And we can do development at a very fast pace as well. That is the benefit.

From SQL query optimization, I would prefer to run the SQL query plan in the SQL itself based on the permissions we have for the developer side. If we don't have them, we will check the SQL complex query to see if we are following the best practices of SQL or not. For example, if we return unnecessary columns in our select statement or if we are using an unnecessary looping order or we have some kind of cursor or background operation happening on the code based on that query. We try to avoid that and optimize it. That's, I guess, the main thing we can use. And if we have large data returned from the SQL query, we try to implement pagination. We try to apply indexing on the particular tables or columns. These are the ways we can improve query performance for

Okay. So I would consider for that, this integrity, data integrity, we would consider as a transaction-based approach. So let's say we're calling from the business logic layer, either from a single stored procedure or from multiple stored procedures. We're trying to insert or update data into multiple tables. Right? So integrity is very important in that case. Like, we are dealing with multiple tables. Right? So in that case, a transaction will be more efficient. And if any exception occurs in any stage of that business logic, so we can revert or roll back the transaction. That will be managed by the business layer as well as from the SQL side. If you're doing things from the same single SP, then we can roll back the transaction. We can use a try-catch inside the stored procedure itself. We can write a log on the catch block, and we can do the rollback of the transaction. So that way we can maintain data integrity in SQL.

So no sequel DB will be used when we follow the JSON-based structure or whenever it's required. There is no transaction-based approach required, or we are dealing with a non-relational database kind of structure. Right? There is no normal license required. Right? So in that case, we can use the NoSQL database. So that in that case, we will have the freedom to add columns or add data based on our requirement at any point without making changes on the database side or schema side. Right? So there is no schema we need to maintain; we just need to maintain the kind of document. Every time we manage, we can update or add the required fields or many fields in that document as well. So it's a kind of JSON-based document, I would say. So I had some experience in the past that we worked with providers, and we have DocumentDB as well, so that we can follow. And even on the.net side, we can use the open-source database like MongoDB. That is more helpful in that case. And if we are working with a multilingual application, for example, we have a customer base as a global label. Right? So that in that case, I would prefer that we use the NoSQL database. So they have a very good throughput in terms of performance. So within a millisecond, we can do the insert and update operation as well for that particular document or particular record. So that gives you a very good benefit of that, and it's also providing good latency, and there will be no performance issue in that kind of database. So that in that scenario, we can use the NoSQL database.

So this is some kind of concept of the throttling, I would say. And we can use the rate limiter. Either we can create a custom action filter from the middleware layer, or we can use the API management from the Azure or AWS side as well. So if you're hosting our API on the cloud environment, right, so we can use the API management, and they provide the rate limiter approach over there as well. So either we can use that or we can create our custom filter for that, and we can apply the throttling, or we can use the rate limiter approach over there. This is mainly because of the security perspective and to prevent if we are exposing our API to the outside world and there are multiple third-party users using our API, then if someone tried to block or flood our API instantly without a rate limit, it will create a problem for other customers. So that's the business approach that people are following nowadays, in this standard or business model, we are providing the rate limit for that. For example, you can make 100 requests within a minute. Or if you are premium, then you can make 1,000 requests within the minute. So that kind of approach is now being used in business. So that way, we can apply this security to our application as well, and we can maintain the overall performance of the application or API instance most of the time.

In this core, there is a user roles returning from the get user or my third. Right. And we apply the not null check as well and count it. If it is 0, it will execute the following. So if we have the null reference exception thrown from that particular logic, we can use the null reference exception as well. And either if instead of writing not null and not count, we can use the any order, like user roles dot any method, that will also handle the null reference as well as there is a record or not. So that way we can avoid the null reference exception in some time cases. And either we can cover the particular used code into the try catch block. In an exception block, in a try catch, we can handle the null.

Okay, so here we don't need to write each and every try case block for multiple operations. So, and it's not part of the solid principle. So if you want to follow the solid principle, then we can create a single responsibility class and, as well as we can create an exception filter. That exception filter links with each and every controller method, or we can also link with or generate with the base controller. Right? And that's the one single point where we can handle the exception of our web application or VPA. So we don't need to write try catch on each and every action method or each and every method. So that way, we can handle the action handling in our case. So, we can use the single responsibility class as an exception handler.

In that application, to handle the large volume of data with complex transactions, right? So I would say there are a couple of options we have, like we can use cash or distributed cash for that to handle the data that we can store in the cache to improve the performance of our application as well. Then we can use RabbitMQ or message queue mechanism, or we can use Azure service bus in that case. So whenever some event occurs in a particular stage, we can publish that data into the queue, and that queue will have subscribers or topics below the subscribers or multiple subscribers that can consume the data and proceed further for the next stage. So in that case, we'll create a good rhythm of the application transaction level, right? It's not on a single transaction or single request; we handle old transactions. Right? So it will be, for example, we maintain a chain of sequence of transactions using this large volume, or we have a complex kind of mechanism. Right? So in the first stage, it will happen, publish into a particular queue, then next queue, or it will be consumed by multiple time triggers or multiple functions. That way, we can make it a smooth process. Like, it will be an asynchronous manner, or we can use the async await keyword on each and every layer from the application layer to business layer to data access layer, right? And we can maintain data by the queue for that. And if it's real-time, it will be consumed by the real-time consumer or real-time consumer from the application side. So that way, we can maintain the application.

So that asynchronous programming pattern is nowadays everyone using it to help the performance to improve the performance of the application. That is the biggest advantage. Right? So each and every stage, I would prefer that the on-action method or the business layer, or the data access layer use the async and await keyword for that. So whenever we have multiple requests coming from the application side or the user side, right, so each and every request will be executing in a parallel basis, not on a first in, first out manner. Right? So the user will not have to wait for the response from the application. So that is the main purpose. So previously, in a traditional framework, the synchronous approach was used. We were using a legacy system. But now, in the modernization of the framework, on.net or.net core, we can use the async and await keyword. So that is the good approach. Everyone should have that.

So from an architecture perspective, applications should be scalable and maintainable. For that, in our design approach, we would consider it as part of our design. Like, we can if you're going with the cloud provider. Right? So whenever it's required, it can be scalable on either a horizontal or vertical basis. Right? It depends on the business requirement. So that's the main purpose. And from a maintainability perspective, if there are any issues with downtime, we should follow the agreement from the cloud provider for that. And based on that, we can use their services and integrate them into the architecture. So, for example, if we have replication running on a multiregion, we can create a disaster recovery scenario for one region or multiple regions as well. And we can also identify downtime based on the SLA. If any patching process occurred on the server side, that will also be addressable from the cloud provider side, and we can inform our user base in advance. From the architecture side, I would consider this a multi-disaster recovery approach for the production environment. And from the security side, we could consider a different solution, like how we've configured the firewall on our application side, how requests travel from the front-end layer to the back-end layer, network-level configuration, and for that. So these are the main scenarios we should cover for that.