API composition pattern
This pattern uses an API composer, or aggregator, to implement a query by invoking individual microservices that own the data. It then combines the results by performing an in-memory join.
The following diagram illustrates how this pattern is implemented.
The diagram shows the following workflow:
-
An API gateway serves the "/customer" API, which has an "Orders" microservice that tracks customer orders in an Aurora database.
-
The "Support" microservice tracks customer support issues and stores them in an Amazon OpenSearch Service database.
-
The "CustomerDetails" microservice maintains customer attributes (for example, address, phone number, or payment details) in a DynamoDB table.
-
The “GetCustomer” Lambda function runs the APIs for these microservices, and performs an in-memory join on the data before returning it to the requester. This helps easily retrieve customer information in one network call to the user-facing API, and keeps the interface very simple.
The API composition pattern offers the simplest way to gather data from multiple microservices. However, there are the following disadvantages to using the API composition pattern:
-
It might not 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.
