In particular, I want to explain a case I recently stumbled upon which made us hate the strategy we've got of splitting the big monolithic application to microservices.
The use case is relatively simple - one wants to make a query concerning multiple entities. They have relations between them nevertheless, the data ideally should be owned by separate microservices in an autonomous way.
The example:
Let's say that the product is a ERP-like and naturally we would have entities like company and invoices. Naturally, we'd went for microservice for the company - let's name it company-srv and one for invoices - invoice-srv. Both of these should own the APIs and DBNow what happens when we want to make a query that is something like:
Get all companies with more than 1000 invoicesor slightly more complex example:
Get all invoices that haven't sent email-report last month for the companies that have this feature enabled.
How do you handle such responsibility - is it in invoice-srv's ownership and it should have a dependency on the other services? How do you keep the performance high with increased row count?
Even if you handle this with additional relations between the 2 DBs between the autonomous services, let's add another more interesting factor to the situations.
The more complex (and quite common) example:
Let's try to intertwine permissions - let's say that the user who is trying to see the results of the above queries, doesn't have permissions for some of the companies? Or even more intriguing - for some of the branches of the companies...Whose responsibility is it to orchestrate the query? Does it become a multi-query operation? Is there going to be a permissions-srv ? What about performance? Pagination?
...
All these are questions we ask when we pick microservices. Otherwise, it would have been a simple JOIN in the monolithic approach....
Are we going backwards? :)
PS:
more on the topic this cool post: https://www.javacodegeeks.com/2016/07/hardest-part-microservices-data.html
