I am creating a microservice architecture.
Suppose I have three services: alpha, beta, gamma
and suppose the end-user sends a request to alpha and the structure is such that the alpha needs to send a request to beta and beta to gamma.
user <===> alpha <===> beta <===> gamma
I also have a kong API gateway so actually, the user sends the request to kong and kong dispatches it the service requested by the user.
The question is, should the internal requests also go through kong or not?
user <===> kong <===> alpha <===> beta <===> gamma
OR
user <===> kong <===> alpha <===> kong <===> beta <===> kong <===> gamma
Note that one of the benefits of using kong is its plugins. For example, if I want to use the correlation-id or Zipkin plugin and trace requests and latency in all the internal services, I need to reach them through kong. But my concern is, doesn't it add latency to the whole system? Is it a recommended practice in microservices architecture or not?
You should avoid strong coupling. Please invest some time in good API design , not with the backend in mind. For me the architecture idea looks somehow like a workflow with an Api gateway in it. You can also think about a compositioning service where the gateway knows this upstream and "the magic" with calling several other apis happens in this service. In this case you won't use the gateway as an esb. The only plugin you will really need is correlation-id.