I have been working on a project with multiple microservices whose communication happens through API calls. Lets say microservice A calls a service provided by microservice B. According to the current implementation, we don't have multiple APIs for the different services provided by Microservice B; instead what we have is a single API which accepts a parameter indicating what service to be invoked.

I think it is a bad practice due to following reason. In current code, what we have to do is to check the parameter using if conditions and invoke the methods in inner layers accordingly.

if (param == service_1) {
    // call service 1 business logic and return
} else if (param == service_2) {
    // call service 2 business logic and return
} else if (param == service_n) {
    // call service n business logic and return

This design would look okay up to limited number of services. But for each service we add to the microservice B, we have to add a if condition in to the above given interface which will end up increasing the complexity of the method.

I think you agree with my concern on above design. At the moment, I am looking for a better way of getting this thing resolved and to come up with a proper design for the API.

I know, providing different API calls for different services is one such proper way. But other than that, what possibilities are there?


1 Answer 1


It sounds like you’d be better off using a queue. Check out RabbitMQ or AWS SQS. Apache also has an open source package for event and/or queue based architecture called Kafka.

More interesting, is AWS SNS service which immediately sends messages out as opposed to waiting to process a queue. This means that your data is guaranteed to be fanned out to its endpoint regardless of if those nodes are up and running. It’s more for mission critical and real-time messaging. Whereas a queue could introduce some latency if those nodes or consumers aren’t online to process the message/payload at the time of initial delivery.

The idea is that with each API request that occurs on a respective micro service, a payload is published to the queue. Subscribers of the queue (which will be your other micro services) can all listen to multiple channels and consume whichever message they find appropriate to fulfill their purpose.


  1. User subscribed to website and hits an API endpoint responsible for publishing that user data to a queue

    1. All other services subscribed to that particular queue will receive the data published by the “Producer”.

    2. This allows you to have a service solely for persisting information to a database, a service for emailing the user a welcome email or a service that fulfills some other action.

If a queue doesn’t sound fitting then you’ll probably want to create a service layer within your middleware micro service.

The service layer will be responsible for storing classes that interact with external systems and other APIs. When a particular endpoint is hit within your API on Service A ,the appropriate Controller (or whatever your entry point is) should load a particular service, execute a request to Service-B and the Controller for Service-A should handle the response data and produce a response for the client machine.

Hopefully this answer helped some.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.