Software composition means the way to build your software product. Basically it deals with high level software architecture diagram where different modules of your software will communicate for specific business goals. In this chapter, we will learn about different software composition patterns widely used in organizations. In microservice, we split each function into one process. Each of these services will be independent and full stack in nature.
Functional decomposition plays an important role in building your microservices. It provides agility, flexibility, and scalability to your application.
Aggregator pattern is the simplest web pattern that can be implemented while developing a microservice. In this composition pattern, a simple web module will act as a load balancer, which means it will call different services as per requirements. Following is a diagram depicting a simple microservice web app with aggregator design. As seen in the following image, the “Aggregator” is responsible for calling different services one by one. If we need to apply any business logic over the results of the service A, B and C, then we can implement the business logic in the aggregator itself.
An aggregator can be again exposed as another service to the outer world, which can be consumed by others whenever required. While developing aggregator pattern web service, we need to keep in mind that each of our services A, B and C should have its own caching layers and it should be full stack in nature.
Proxy microservice pattern is a variation of the aggregator model. In this model we will use proxy module instead of the aggregation module. Proxy service may call different services individually.
In Proxy pattern, we can build one level of extra security by providing a dump proxy layer. This layer acts similar to the interface.
As the name suggests, this type of composition pattern will follow the chain structure. Here, we will not be using anything in between the client and service layer. Instead, we will allow the client to communicate directly with the services and all the services will be chained up in a such a manner that the output of one service will be the input of the next service. Following image shows a typical chained pattern microservice.
One major drawback of this architecture is, the client will be blocked until the entire process is complete. Thus, it is highly recommendable to keep the length of the chain as short as possible.
Branch Microservice Pattern
Branch microservice is the extended version of aggregator pattern and chain pattern. In this design pattern, the client can directly communicate with the service. Also, one service can communicate with more than one services at a time. Following is the diagrammatic representation of Branch Microservice.
Branch microservice pattern allows the developer to configure service calls dynamically. All service calls will happen in a concurrent manner, which means service A can call Service B and C simultaneously.
Shared Resource Pattern
Shared resource pattern is actually a conglomerate of all types of patterns mentioned earlier. In this pattern, the client or the load balancer will directly communicate with each service whenever necessary. This is the most effective designing pattern followed widely in most organizations. Following is a diagrammatic representation of the Shared Resource design pattern.