OK, let first give you my view of a typical microservice architecture, from top to bottom:
- UI consumes microservices through a proxy. The proxy work as a router and aggregator exposing high level API to your microservices
- Proxy layer will aggregate microservices and combine them to fulfill the high level task.
- Microservices. They are fulfilling very small specific tasks, for example Users can be spread in several microservices, typically with an isolated data store.
- Event bus, message queue or something similar, provides infrastructure for message passing, consistency, load balancing and sometimes data replicas.
You can place load balancing, fail over on every layer or the layer you like most.
I think reporting is a very broad domain. You need to cut it up in little pieces first in order to decide where you will put each one. At least, think about the problem as three very broad topics.
- Real time reporting, that is reports of live data, like list of orders, monitoring data, status. Requires access to real time data.
- Aggregated or summarized reports in time, that is totals for past periods. Can be read from replicated read-only data.
- Data mining reports, that is reports that will need to analyze all your past data (archived?). They will require a data warehouse, data lake, you name it. They require to process or preprocess data and store it in a special data store, usually by incremental processing over time.
Now, you see that reporting will need to correlate all the data of different microservices.
- For real time reports, you probably need to place contracts on the needed microservices.
- For Aggregated or summarized reports in time, you can access directly existing read replicas of the needed microservices and deal with the schema change in the reporting layer. That is if the period of read replicas match your reporting needs.
- For data mining, OLAP, you are better getting a data scientist in your reporting team, because you will be dealing with real big data issues.
Depending on the importance of your reporting needs, you will need to spread part in microservices, create some specialized ones, and sync with your data strategy, like how big will your real time data windows would be, how big your historic data window will be, and how often you will be archiving data.
Now, creating the report and generating a PDF or Excel file, belongs to the reporting layer. And I use the word layer on purpose. Reporting will need microservices doing data gathering (probably consuming other microservices, accessing read-only replicas or archived data), report processing, file generation and so on. They need to expose high level interfaces at the proxy layer to be consumed by the UI, such as select a report, fill report parameters, retrieve a file.
- Create a Reporting layer.
- For data gathering: consume microservices for real time simple reports, as microservices aggregation will increase in complexity and performance will suffer. Create a strategy to access read-only replicas directly. Create a data warehouse, data lake and get a data scientist if dealing with big data. Explore graph databases like Graph Engine www.graphengine.io or Neo4j neo4j.com
- For report processing: build the needed microservices that consume data from your data gathering microservices and use their own isolated data store for the report outcome.
- UI: create your high-level microservices on to the proxy layer.