as I understand it micro-services are autonomous and have complete control over their own data and therefor each micro-service has a dedicated database.

I was wondering what would be the approach to implement reporting in a micro-services architecture, if reports depend on data that exists in multiple databases where each database is governed by its own micro-service.

closed as too broad by user22815, durron597, Bart van Ingen Schenau, Ixrec, user53019 Oct 3 '15 at 23:50

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask – gnat Oct 19 '14 at 6:47
  • Micro services address a different scenario than reporting. The network latencies make the use of micro services prohibitive in any but the most trivial scenarios. In the end, you do need a single database (clustered or otherwise) to collect all data, clean it up and prepare it for presentation. – Panagiotis Kanavos Oct 20 '14 at 15:39
  • Is it prohibitively slow to simply call all the other microservices when you need their data? Performant microservices are certainly possible, especially since you don't need a separate physical machine for each service. Where I work services are deployed to one or more machine clusters, and each cluster has tons of services that can easily talk to each other "locally". – Ixrec Oct 3 '15 at 19:38

I'm not exactly sure why a micro-service should have 'complete control over their own data'. What I understood is, that a micro-service should be stateless. That means it should not depend its 'action' on some state (possible from a database), but only from the 'input' data (eg: message) - therefore it's action should be repeatable when the 'same' input triggers the action at any given time.

A service which depends on 'changing-over-time' reporing data may not have those properties, but it totally depends on your use-cases. If you 'just' trigger the generation of a report, the output may (and must) change over time.

Perhaps a micro-service architecture may not be the best fit for a reporting applicaction...


Yes, micro-services should operate on their own datasets, but this doesn't have to mean individual databases, it can be schemas or even just a few tables in an existing DB. Just as long as you know who has ownership over what data, you should be good.

But reporting... typically this does not occur on the live databases, you would extract data from the main DBs to a reporting DB where you run all manner of slow and intensive queries. How you get the data extracted is up to you - either a dedicated SQL task, or you have a method on your services that exports data for import into the report DB.