DEV Community

loading...

Discussion on: Why do microservices need an API Gateway?

Collapse
bobbypriambodo profile image
Bobby Priambodo

Thanks for the article. One question: do you think inter-service call should also done through the API gateway? For example, should the Ruby service call the Golang service via the gateway in this case?

Collapse
rahul_ramfort profile image
Rahul Author • Edited

Great question Bobby. There are no hard and fast rules. It is a matter of choice if you want any of the functionalities from your api gateway or not.
For instance, for services that aren't exposed to the outside world, the authentication/security can be done either at the application layer or at the network layer or both. We are good with the security at the network layer and as a result, we don't route the inter-service calls through our api gateway as of now. (We use kong)

Having said that, let's say, if we need metrics for inter-service calls going forward, we might rethink about this and route the inter-service calls through Kong.

Collapse
kanmeiban profile image
Sava Chankov • Edited

One microservice should not call another microservice. This introduces coupling and is worse than the monolith – actually it creates a distributed monolith. Instead the services should use publish/subscribe event log to exchange data.

Collapse
bobbypriambodo profile image
Bobby Priambodo

So do you mean in such systems there would no longer be a request-response communication model between the services? I am currently having a hard time imagining such kind of systems (especially for customer-facing SaaS apps), but it might just be because I haven't seen it yet.

Thread Thread
kanmeiban profile image
Sava Chankov • Edited

Yes. The most important property of a well designed distributed architecture is that individual services are operationally completely independent of each other. That is if one service goes down the rest will continue to function and the system stays available. When services query each other monolith’s coupling is still there with the added ‘benefit’ of distribution faults. Why not stay with the monolith in first place?

Collapse
zeroisaloop profile image
Bobbie Tables

For an infra composed of hundreds of very chatty microservices, most of which are interdependent, and where RMQ cannot handle the traffic, what do you recommend for handling eventing? We're using Kafka now, but curious for your thoughts.

Thread Thread
kanmeiban profile image
Sava Chankov

We use Kafka too. For not so overwhelming loads and Ruby based services I would consider Eventide with PostgreSQL store.