API Gateway Pattern
In this tutorial, we are going to discuss Design Patterns of Microservices Architecture which is The API Gateway Pattern. We will use this pattern and practice when designing microservice architecture.
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 from object-oriented design, but it is part of a distributed system reverse proxy or gateway routing and uses a synchronous communication model.
We said that It is similar to the facade pattern of Object-Oriented Design, so it provides a single entry point to the APIs encapsulating the underlying system architecture.
The pattern provides a reverse proxy to redirect or route requests to your internal microservices endpoints. An API gateway provides a single endpoint for the client applications, and it internally maps the requests to internal microservices.
In summary, the API gateway locates between the client apps and the internal microservices. It is working as a reverse proxy and routing requests from clients to backend services. It also provides cross–cutting concerns like authentication, SSL termination, and cache.
You can see the image that is collect client requests in a single entry point and route request to internal microservices.
So there are several client applications connected to a single API Gateway in here. We should care about this situation because if we put here a single API Gateway, that means its possible to single-point-of-failure risk in here. If these client applications increase or add more logic to business complexity in API Gateway, it would be an anti-pattern.
API Gateway service can be growing and evolving based on many different requirements from the client apps. That’s why the best practice is splitting the API Gateway into multiple services or multiple smaller API Gateways. We will discuss the BFF-Backend-for-Frontend pattern later.
In summary, we need to care about using a single API Gateway, it should be segregated based on business boundaries of the client applications and not be a single aggregator for all the internal microservices.
Main Features of API Gateway Pattern
The API Gateway pattern provides several benefits. Since we accommodate the client request and route the internal microservices, we can handle some useful features into API Gateway. Let’s see features.
Reverse proxy or gateway routing
This is part of gateway routing pattern features. The API Gateway provides a reverse proxy to redirect requests to the endpoints of the internal microservices. Usually, It is using layer 7 routing for HTTP requests for request redirections. This routing feature provides to decouple client applications from the internal microservices. So it is separating responsibilities on the network layer.
Another benefit is abstracting internal operations, API Gateway provides an abstraction over the backend microservices, so even there are changes on backend microservices, it won’t be affected to client applications. That means don’t need to update client applications when changing backend services.
Requests aggregation
This is part of gateway aggregation pattern features. API Gateway can aggregate multiple internal microservices into a single client request. With this approach, the client application sends a single request to the API Gateway. After that API Gateway dispatches several requests to the internal microservices and then aggregates the results and sends everything back to the client application in 1 single response. The main benefit of this gateway aggregation pattern is to reduce chattiness communication between the client applications and the backend microservices.
Cross-cutting concerns and gateway offloading
This is part of gateway offloading pattern features. Since API Gateway handles client requests in a centralized place, its best practice to implement cross-cutting functionality on the API Gateways.
The cross-cutting functionalities can be;
- Authentication and authorization
- Service discovery integration
- Response caching
- Retry policies, circuit breaker, and QoS
- Rate limiting and throttling
- Load balancing
- Logging, tracing, correlation
- Headers, query strings, and claims transformation
- IP allowlisting
As you can see that we have understood the API Gateway Pattern and the benefits. Now we will design our e-commerce architecture by adding API Gateway.
Design API Gateway — Microservices Communications Design Patterns
We are going to iterate our e-commerce architecture by adding an API Gateway pattern.
As you can see that we have added to single API Gateway in our application.
This will handle the client requests and route the internal microservices, also aggregate multiple internal microservices into a single client request, and performs cross-cutting concerns like authentication and authorization, rate limiting and throttling, and so on.
We will continue to evolve our architecture, but please look at the current design and think about how we can improve the design?
As we said that there are several client applications connected to a single API Gateway here. We should care about this situation because if we put here a single API Gateway, that means its possible to single-point-of-failure risk in here. If these client applications increase or add more logic to business complexity in API Gateway, it would be an anti-pattern.
So we should solve this problem with the BFF-backends-for-frontends pattern.