API gateway pattern
The API gateway pattern is recommended if you want to design and build complex or large
microservices-based applications with multiple client applications. The pattern is similar to
the facade pattern
The pattern provides a reverse proxy to redirect or route requests to your internal microservices endpoints. An API gateway provides a single endpoint or URL for the client applications, and it internally maps the requests to internal microservices. A layer of abstraction is provided by hiding certain implementation details (for example, the Lambda function name and version), and additional functionality can also be added on top of the backend service, such as response and request transformations, endpoint access authorization, or tracing.
You should consider using the API gateway pattern if:
-
The number of dependencies for a microservice is manageable and does not grow over time.
-
The calling system requires a synchronous response from the microservice.
-
You have low latency requirements.
-
You need to expose one API to collect data from multiple microservices.
Use case
In this use case, a customer makes regular monthly payments in an insurance system that consists of four microservices deployed as Lambda functions ("Customer," "Communication," "Payments," and "Sales"). The “Customer” microservice updates the customer database with the monthly payment details. The “Sales” microservice updates the sales database with relevant information that helps the sales team follow up with the customer for cross-selling opportunities. The “Communication” microservice sends a confirmation email to the customer after the payment is successfully processed. Finally, the “Payments” microservice is the overall system that the customer uses to make their monthly payment. The pattern uses web services to integrate the "Customer," "Sales," and "Communication" subsystems with the "Payments" microservice.
There are three challenges to using this pattern for this use case:
Synchronous calls are made to downstream systems, which means that any latency caused by these subsystems affects the overall response time.
Running costs are higher because the “Payments” system is waiting for responses from the other microservices before responding to the calling system. The total running time is therefore relatively higher compared with an asynchronous system.
Error handling and retry are handled separately for each microservice inside the “Payments” system, not by the individual microservices.
The following two examples outline how to use the API gateway pattern to integrate microservices by using multiple API gateways or one API gateway.
Multiple API gateways
In the following illustration, each microservice has its own API gateway. The "Payments" microservice calls out individual systems and implements the API gateway pattern.
Single API gateway
In the following illustration, each microservice is deployed as a Lambda function but all microservices are connected by the same API gateway.
