Aggregator Microservice Design Pattern
Aggregators call multiple services to implement the functionality required by the application. It can be a simple Web page that processes and displays the retrieved data. It can also be a higher-level composite microservice that adds business logic to the retrieved data and further publishes it as a new microservice, which conforms to the DRY principle. Also, each service has its own cache and database. If the aggregator is a composite service, then it also has its own cache and database. Aggregators can scale independently along the X and Z axes.
Proxy Microservice Design Pattern
In this case, the client does not aggregate data, but calls different microservices based on differences in business needs. The proxy can just delegate the request, or it can do the data transformation work.
Chained Microservice Design Pattern
In this case, service A will communicate with service B after receiving the request, and similarly, service B will communicate with service C. All services use synchronous messaging. The client will block until the entire chain of calls is complete. Therefore, the service call chain should not be too long to prevent the client from waiting for a long time.
Branch Microservice Design Pattern
This pattern is an extension of the aggregator pattern and allows two chains of microservices to be invoked at the same time,
Data Sharing Microservice Design Patterns
Autonomy is one of the design principles of microservices, which means that microservices are full-stack services. But when refactoring an existing "monolithic application", SQL database denormalization can lead to data duplication and inconsistency. Therefore, this design pattern can be used in the transition phase of monolithic application to microservice architecture, as shown in the following figure:
In this case, some microservices may share cache and database storage. However, this is only possible if there is a strong coupling between the two services. This is an anti-pattern for new microservice-based applications.
Asynchronous Messaging Microservice Design Pattern
Although the REST design pattern is very popular, it is synchronous and can cause blocking. Therefore some microservice-based architectures may choose to use message queues instead of REST request/response