I'm working on an application with N microservices, some features of this application need to communicate with more than 4 services to work.
In one of these features, I need to request entities by ID for other services to continue processing. Would it be correct to adapt this "GET Request" to a message broker?
in service 1 - creating a producer that sends only one ID to the queue
in service 2 - a consumer that listen this ID, gets the entity and a producer that sends this entity to another queue
in service 1 - a consumer that obtains this entity and continues the processing that starts after it has sent the ID to the first queue
or it doesn't make sense and is just over-engineering. After all, I would have to create two queues, which will only have this purpose. Or should I stick to the standard HTTP request?
I was required to implement the message broker for the internal communication of the services, but for me apparently there will have to be a complete refactoring of the architecture to encompass events to make sense of this type of communication, otherwise it would just be a hack, literally transforming a simple HTTP GET Request into a heap of queues and operations that need to be synchronous becoming asynchronous.