ratneshsingh35

Thanks for sharing, If you include scale then the situation might be tricky, you may need to have different DBs and endpoints there will be a limit on how much vertically you can scale, with that thing in mind this problem is not avoidable, but the distributed transaction is still avoidable using eventual inconsistency or a batch proces.

It seems the term scaling changes everything, SOA is good but in many cases scaling the SOA might not solve the problems and you need to pick the path of optimization, and microservices are the possible way to optimize the service, Now if you need transaction (not in all cases) as well then It becomes tricky.

thanks for sharing this, good read

in one of the situation, we had a similar problem of scaling and consistency not going hand in hand, at that time batch process solves Lot of our problems.

yes they will not mostly care and will insist on microservices, but they will not ask for the distributed transaction, I will always try to get the thing done by a batch process instead of services calling each other.

yes, thanks for reading

I agreed, I like these patterns but I never encourage anyone to start with these patterns, First build a simple monolith to handle the situation, if there is a hard problem then and only then these should be applied, But these days I am seeing quite opposite though, I don't see enough evidence to start with these patterns and always use them as rule of thumb .

What I always try to learn is, whether we need these patterns in the first place and do we always need them, But if we do, then these seem handy

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 )