What is the problem?

How to implement queries in a microservice architecture?

How do you support the need for these queries that span data owned by more than one service?

Context

A simplified overview of clients Client-1, Client-2, and Client-3 requires different data from individual services Order-service, Coupon-service, and Promotion service of a microservice architecture. All are accessible via different protocols: REST, GraphQL, and gRPC.

The picture above illustrates such a microservice architecture. Even if your microservices do not use different communication protocols such as in this example: Talking to multiple hosts might still require multiple ways of authentication, understanding different styles of API design, collecting and aggregating joined data from various services, etc...

Approach One: API gateway Pattern as the single entry point

An API gateway pattern might help us with this complexity. The main purpose of an API gateway is to be the single entry point for our microservice architecture. It is built on top of your individual services and routes requests of clients to these services. This API gateway does not contain or know of any business or domain logic of the individual services.

An API gateway sits between our microservices and the clients who want to access these services. The API gateway provides a unified interface to the clients and hides implementation details of the services Order-service, Coupon-service, and Promotion-service.

Advantages of API gateways

• This enables clients to have a single point of entry to your system, thus, making it more accessible
• the API gateway can be used to centralize and handle topics such as Permission handling, API security, Authentication, and Policies (rate limits, allow-listing, etc.)

Disadvantages of API gateways

• The API gateway is another piece of software in our system that has to be developed, deployed, and maintained.
• A single point of entry to our application might also become a bottleneck in two different ways.
• First, the API gateway must be highly scalable. Because it is another layer between every request of the client and our microservices. So it needs to have as little impact on the request latency as possible.
• Second, it can slow down development speed, Because every microservice must be exposed via the API gateway.

Approach Two: API Composition Pattern

Clients could want to query data of multiple microservice at the same time or just a small portion of the data from a single microservice. To solve these needs, the API composition pattern may be applied.

Each composition could also be defined as an aggregate of the microservices or a join of the microservices behind the API gateway to fit the client's need and improve the developer experience.

Advantages of API Composition Pattern

• Hide legacy systems and saves time for refactoring
• Makeup bad Design decisions apply a new simplest interface.
• Lightweight solution.

Disadvantage of API Composition Pattern

• It cannot be suitable for complex queries and large datasets that require in-memory joins.
• Your overall system becomes less available if you increase the number of microservices connected to the API composer.
• Increased database requests create more network traffic, which increases your operational costs.

As a Result

• In this article, we took a brief look into two approaches to handling distributed queries on microservices architectures. API Gateway and API Composition are a solution that would be easier to get started with.
• API gateways and API composition are helpful tools to reduce the complexity of microservice architectures. These patterns can help with handling access and monitoring of the overall system, as well as enabling clients to request data as they expect it.
• In general, due to the much higher complexity, it is suggested that only when appropriate conditions exist and have obvious appeal, the transition from API composition to CQRS should be started. I will explain the CQRS pattern in the next article.

You can review our open source sample API-gateway with the API-composition pattern project that I prepared with my friend.

You can check this link to read the previous part, Distributed Management Problem.

Thanks for Reading…

References

• https://microservices.io/patterns/data/api-composition.html
• https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/api-composition.html