Comment by Mario Hartman on "What's the best approach for microservices to speak with each other?"

There are many alternatives to answer this question and always depends on the use cases of your application.

In my experience REST apis are the easy way to go, but queues or topics are easy to implement as well. In my last project we ended up with a hybrid approach where the communication with some services was using rest and in other places where the order of the messages was important we used queues.

So the bottom line is: you need to clearly understand the requirements of the application, you really need to know the how the data fill flow into your app and base on that create the the constraints that will help you to decide what's the best solution. That being said, I have one recommendation, please start from the easy and then iterate over the solution until you get the final architecture.

I would say that the biggest bottleneck in the project was the implementation of the messages. If service A sends a message to service B and is waiting a response, the response won't be sync, I mean the response from service B won't the response of the method call to send the message as you can expect with REST so in this case what will happen is that you design will need to take account messages that will arrive to services in an async way making the programming model a little bit more complex than using REST. There is a nice advantage and it's that if you have multiple instances of service X listening to the same queue you can use the "competing consumers" model to get load balancing out of the box from the queue service (this works well on ActiveMQ) so you can avoid adding an extra service just to do the load balancing of the microservices.

Hopefully this helps you

Search Hashnode