Collecting Consolidated Data in a Service Oriented Architecture

Question

Computer networks

Good day.

Imagine that in the simplest case we have 2 services. The first provides access to the client base, the second contains financial data (orders, purchases, invoices, transfers of funds from account to account, whatever). By chance, these services are on different machines, and have different databases. Consumers of these services are doing great: the customer base is growing, the number of orders is increasing. Users are provided with statistics of their operations, everything is smooth. And now we need to build some reporting that aggregates financial service data with reference to the client. For example, we have become a tax agent ( Wiki ), and we want to generate 2NDFL certificates for all our clients with a breakdown of income by month ( an example of a certificate). If it were one database, it would be one cross-query on tables relating to both personal and financial data (you can even immediately select XML, which is immediately given to View, which builds reports). It's guaranteed to be fast. And what is the right thing to do in case of staggered data? Select first a list of all customers on one side, then income data on the other, and glue them in the code? Isn't the speed of formation at times reduced?

Answer 1

Isn't it easier to rely on the capabilities of a DBMS? Many DBMS have the ability to consolidate queries to different databases. Anyway PostgreSQL. And even MySQL.
It is clear that it is better to have data on one server. So here it is possible to use replication . For reports, it is not particularly critical to have all the data guaranteed up to date.
No, you can of course stir up map-reduce. But you only need it for reports?