Why API Gateway is recommended for Microservices?

Question

For microservices, the common design pattern used is API-Gateway. I am a bit confused about its implementation and implications. My questions/concerns are as follows:

1. Why other patterns for microservices are not generally discussed? If they are, then did I miss them out?
2. If we deploy a gateway server, isn't it a bottleneck?
3. Isn't the gateway server vulnerable to crashes/failures due to excessive requests at a single point? I believe that the load would be enormous at this point (and keeping in mind that Netflix is doing something like this). Correct me if I am wrong in understanding.
4. Stream/download/upload data (like files, videos, images) will also be passing through the gateway server with other middleware services?
5. Why can't we use the proxy pattern instead of Gateway?

From my understanding, in an ideal environment, a gateway server would be entertaining the requests from clients and responding back after the Microservices has performed the due task.

Additionally, I was looking at Spring Cloud Gateway. It seems to be something that I am looking for in a gateway server but the routing functionality of it confuses me if it's just a routing (redirect) service and the microservice would be directly responsible for the response to the client.

Translocation

"API-Gateway" is such a general term. Even a proxy is a kind of gateway. – Omphale

Answer 1

The gateway pattern is used to provide a single interface to a bunch of different microservices. If you have multiple microservices providing data for your API, you don't want to expose all of these to your clients. Much better for them to have just a single point of entry, without having to think about which service to poll for which data. It's also nice to be able to centralise common processing such as authentication. Like any design pattern, it can be applied very nicely to some solutions and doesn't work well for others.

If throughput becomes an issue, the gateway is very scalable. You can just add more gateways and load balance them

There are some subtle differences between proxy pattern and API gateway pattern. I recommend this article for a pretty straightforward explanation https://blog.akana.com/api-proxy-or-gateway/

Drouin

Answer 2

In the area of microservices the API-Gateway is a proven Pattern. It has several advantages e.g:

• It encapsulate several edge functionalities (like authentication, authorization, routing, monitoring, ...)
• It hides all your microservices and controls the access to them (I don't think, you want that your clients should be able to access your microservices directly).
• It may encapsulate the communication protocols requested by your microservices (sometimes the service may have a mixture of protocols internally which even are only allowed within a firewall).
• An API-Gateway may also provide "API composition" (orchestrating the calls to several services an merge their results to one). It s not recommended, to implement a such composition in a microservice.
• and so on

Implementing all these feature in a proxy is not trivial. There is a couple of API-Gateways which provide all these functionalities and more like the Netflix-Zuul, Spring-Gateway or the Akana Gateway.

Furthermore, in order to avoid your API-Gateway from being a bottleneck you may :

• Scale your API-Gateway and load balance it (as mentioned above by Arran_Duff)
• Your API-Gateway should not provide a single one-size-fits-all API for all your clients. Doing so you will, in the case of huge request amount (or large files to down/up load) for sure encounter the problems you mentioned in questions 3 and 4. Therefore in order to mitigate a such situation your Gateway e.g may provide each client with a client specific API (a API-Gateway instance serves only a certain client type or business area..). This is exactly what Netflix has done to resolve this problem (see https://medium.com/netflix-techblog/embracing-the-differences-inside-the-netflix-api-redesign-15fd8b3dc49d)

Unconformable

Answer 3

1.Why other patterns for microservices are not generally discussed? If they are, then did I miss them out? There are many microservice pattern under different categories such as database , service etc .This is a very good article https://microservices.io/patterns/index.html

2.If we deploy a gateway server, isn't it a bottleneck?

Yes to some extent .Q3's answers image will answer this.

3.Isn't the gateway server vulnerable to crashes/failures due to excessive requests at a single point? I believe that the load would be enormous at this point (and keeping in mind that Netflix is doing something like this). Correct me if I am wrong in understanding.

4.Stream/download/upload data (like files, videos, images) will also be passing through the gateway server with other middleware services? Why can't we use the proxy pattern instead of Gateway?

The use case for an API Proxy versus an API Gateway depends on what kinds of capabilities you require and where you are in the API Lifecycle. If you already have an existing API that doesn’t require the advanced capabilities that an API Gateway can offer than an API Proxy would be a recommended route.

You can save valuable engineering bandwidth because proxies are much easier to maintain and you won’t suffer any negligible performance loss. If you need specific capabilities that a proxy doesn’t offer you could also develop an in-house layer to accommodate your use case. If you are earlier in the API lifecycle or need the extra features that an API Gateway can provide, then investing in one would pay dividends.

Galatians

An API gateway is also a proxy dude – Omphale