Search code examples
architecturemicroservices

How to handle reporting in microservices architecture


I'm currently working within a microservices architecture where all services communicate via a message bus. In this setup, only one service (App service) interacts directly with the client through REST calls. However, we're encountering a challenge with report generation. When a client requests a report, the App service sends a message to the reporting service via the message bus and waits for the report to be generated. As this process is event-driven and can take several seconds or even minutes, we are exploring the best approach to handle the client side. One solution I'm considering is to establish a direct HTTP call from the client to the reporting service. However, I'm aware that this might be seen as somewhat against the microservices pattern. I would appreciate any suggestions or insights on how to handle this scenario effectively.

here is the architecture enter image description here


Solution

  • I feel that your app service has the role of an API gateway for handling client requests, whereas your actual system uses the message bus for internal communication. So you are using synchronous communications externally, but asynchronous communications internally. I assume that the HTTP call from the app service back to the client is actually a synchronous REST response and the latency arises from the asynchronous message bus.

    So my thoughts on this:

    Is there a need to use the app service as a gateway? This might be the case if there are other clients using the app service for different kinds of calls. Using a direct client-to-microservice communication (as you have mentioned in your question) is not generally against a microservices architecture, but creates a stronger coupling between the client and the microservice - see also this article for a more detailed analysis.

    On the other hand, are there any other internal services using the message bus? For what reason did you chose the asynchronous approach internally? If you could change this to a synchronous communication (i.e. REST) between the app service and the other internal services including the reporting service, you could also avoid the issue.