[supermatt]

Services can talk to other services. i.e. In your example, the order service can speak to the inventory service to change the stock level. The 'API controller' (this is also a service!) can speak to the inventory service to get the current inventory - but it shouldn't be responsible for handling the transactions of other services.

I think the premise of using a monolithic service (your API "Controller") to handle transactions that it simply shouldn't be concerned with is the main problem here. i.e the problem is that the transaction should not be distributed, not that it is handled through multiple services.

I'm further confused at the reconciliation that seems to occur later in your example. Why is it bypassing the services and writing directly to the service DB itself?

[agreenlake]

Yep. The article seems to muddle up and conflate a bunch of poor practices with "microservices." All the "problems" given are really just poor decomposition of the system into non-discrete components. The "audit" solution is a bit kludgy too.

[hinkley]

> poor decomposition of the system into non-discrete components.

You can tar an awful lot of microservices with that brush.

[ratneshsingh35]

in the first place, the components should not be decomposition like this, But you can't control everyone , But if It happen and went to production, the only thing you can do it is make it better, that what I have done in many products (using auditor or arbitrator )