Retrieve Data From Multiple Microservices

In microservice pattern, microservices are suppose to own their own database to achieve best independent scalability. However, highly distributed data brings challenges to client app that needs data from multiple microservices which is a common requirement. For example a Order screen may need data from User, Product and Shipping microservices. Calling multiple APIs and aggregate information on the client side is not a efficient and clean solution. The following two solutions are common patterns to use.

API gateway

Create a aggregation microservice, as an API Gateway, to provide data to the client side. Sometimes the API gateway is also called the backend for frontend (BFF) layer. API gateway sit between client app and backend microservices.

Having a single API Gateway aggregating many internal microservices can be a risk as it acts as a monolithic aggregator/orchestrator thus making backend microservices not loosely coupled anymore. Therefore, the API Gateways should be segregated based on business boundaries and client apps. Using multiple API gateway is usually better and we should build each client app its own customized API gateway (or BFF) to achieve best efficiency.

Besides the risk of introducing service coupling, API gateway can also add service response time and also requires additional development cost.

View tables

Create read only tables with format customized for client apps. Data are populated in advance from multiple microservices. This table can also serving the reporting purpose. The view tables can improve the call efficiency significantly since no real-time data aggregation is required.

One of the downsides of this solution is that the data in the view table may have some time delays thus we need to embrace eventual consistency of data.