PRABATH'S TECH BLOG

When it comes to Microservices architecture, the deployment of Microservices plays a critical role and has the following key requirements. Ability to deploy/un-deploy independently from other Microservices. Developers never need to coordinate the deployment of changes that are local to their service. These kinds of changes can be deployed as soon as they have been tested. The UI team can, for example, perform A|B testing and rapidly iterate on UI changes. The Microservices Architecture pattern makes continuous deployment possible. Must be able to scale at each Microservices level (a given service may get more traffic than other services). Monolithic applications are difficult to scale individual portions of the application. If one service is memory intensive and another CPU intensive, the server must be provisioned with enough memory and CPU to handle the baseline load for each service. This can get expensive if each server needs high amount of CPU and RAM, and is exacerbated i

In the typical filter or handler pattern  we have set of data and filters/handlers. We are filtering the available data set using available filters. These filters may have some dependencies(In business case this could be the sequence dependency or data dependency) like filter 2 depends on filter 1 and some filters does not have dependency with others. With the existing approach, some time consuming filters are designed to use several threads to process the received records parallely to improve the performance. However we are executing each filter one after another.  Even Though we are using multiple threads for high time consuming filters, we need to wait until all the record finish to execute the next filter. Sometimes we need to populate some data from database for filters but with the existing architecture we need to wait until the relevant filter is executed. We can improve this by using non blocking approach as much as possible. Following diagram shows the proposed