Design Patterns for Microservice Architecture – API Gateway

In Microservice Architecture, the UI usually connects with multiple Microservices. If the Microservices are finely grained (FaaS), the Client may need to connect with lots of Microservices, which becomes chatty and challenging. Also, the services, including their APIs, can evolve. Large enterprises will like to have other cross-cutting concerns (SSL termination, authentication, authorization, throttling, logging, etc.).

One possible way to solve these issues is to use API Gateway. API Gateway sits between the Client APP and the Backend Microservices and acts as a facade. It can work as a reverse proxy, routing the Client request to the appropriate Backend Microservice. It can also support the client request’s fanning-out to multiple Microservices and then return the aggregated responses to the Client. It additionally supports essential cross-cutting concerns.

Pros

• Offer loose coupling between Frontend and backend Microservices.
• Reduce the number of round trip calls between Client and Microservices.
• High security via SSL termination, Authentication, and Authorization.
• Centrally managed cross-cutting concerns, e.g., Logging and Monitoring, Throttling, Load balancing.

Cons

• Can lead to a single point of failure in Microservice Architecture.
• Increased latency due to the extra network call.
• If it is not scaled, they can easily become the bottleneck to the whole Enterprise.
• Additional maintenance and development cost.

When to use API Gateway

• In complex Microservice Architecture, it is almost mandatory.
• In large Corporations, API Gateway is compulsory to centralize security and cross-cutting concerns.

When not to use API Gateway

• In private projects or small companies where security and central management is not the highest priority.
• If the number of Microservices is fairly small.

Enabling Technology Examples

Amazon API Gateway, Azure API Management, Apigee, Kong, WSO2 API Manager