Connecting to gateway scalability issue

[vahidvdn]

It seems all the requests are going to be sent to the gateway service. Since one of the issues that microservices resolve is scalability, in this case, it seems we should vertically scale the server (not horizontally). Can the front side talk to each microservice instead of the gateway? Any idea?

[YisusYaro]

The api gateway scales well both horizontally and vertically.

[vahidvdn]

@YisusYaro How about having a gateway for each microservice?

[YisusYaro]

@YisusYaro How about having a gateway for each microservice?

Talking about nestjs, having a gateway for each microservice for me it's definitely not good idea, you will to create two events loops, using more ram needlessly, you can directly create an hybrid aplication (http and other transport).

Assuming that you create an hybrid aplication, this option is the best for scalability if you have the hardware necesary for run pararely, but if you don't have the suficents cores, you will to use more ram needlessly and finally cpu time will be shared.

Even if you have the hardware, direct client-to-microservice communication have other disventages, for me an microservice should not have the responsability of secure it's comunication, or validate jwt for example.

I always try to create MICROservices focuseds in their utility, yes MICRO in caps.

But, how to resolve this?, You need to secure thar do not block the event loop in your gateway, this maitain a fast entry for client petitions, taking advantage of the asynchronism of nodejs, and finally you can create reals microservices.

If you do not block the gateway, and anyway you have so much latency, you can scale your gateway horizontally, but maintaing the advantages of having only an entry for you app.

[vahidvdn]

@YisusYaro Thanks for your explanations. They make sense to me. But, here is my concern. One of the reasons that we use microservices is that if one part of the project is down, the user is not going to be blocked, so whenever that part is up again, the message broker can give the message to that part. But in this case, if the gateway itself is going to be down, what will happen?

[avifatal]

@vahidvdn I think you got a big point here, if you want parts of your app to be alive while other parts are down, youll need slim controllers for each microservice and you should reuse the authentication on these controllers/gateways.

The internal communication (microservice to microservice) should be unsecured (maybe pass the user info inside the context for the benefit of createdBy and updatedBy) .

this way if one MS is down, the others are still functioning and secured (as long as they are not totally depending on each other, because in this case, one microservice is down the entire stack will be down...)

[vahidvdn]

@avifatal So you mean we should have a gateway for each microservice separately?

[avifatal]

@vahidvdn in my opinion yes. if you want each MS to be independent, you don't want to create single point of failure - AKA one gateway for all. (it makes security a little bit more complex). On the other hand, if all MSs are relaying on each other and they speak frequently, I would go with the current architecture presented in this wonderful repo. I think the biggest drawback of nest is that its micriservices mechanism is not a real framework its just an abstraction of communication layer. once things like security will be solved there, it would make it really convenient to use. @YisusYaro Ill be happy to know your thoughts about this issue (security and single point of failure wise)

[sinhpn92]

Each gateway for each service doesn't solve your issue @vahidvdn. It won't solve your problem. The way you give is just a situational solution and it is not a good way. You can research about NodeJS Microservices Zero Downtime.

[mxkh]

@vahidvdn API gateway scaling horizontally very well. You could do that with K8S HPA and CA. The benefit of having one API gateway is that you have a single entry point to your microservices that will

• Rate limit
• Auth
• Communication through different protocols with your microservices

and many other valuable things. Otherwise, you will repeat all these tasks for each microservice in your cluster.

[vahidvdn]

Thank you guys, this is already fixed for me. Thanks for the collaboration