[usaar333]

> This argument I'll buy, but there is a lot of really good work going into orchestration like kubernetes which makes a lot of these concerns much lower.

Can you explain more how kubernetes help with distributed transactions? I was aware they are more of a management system for microservices, not something that handles db transactions.

I've found splitting a monolith into microservices very painful because it prevents you from easily having all-or-nothing db commit semantics. It's a lot easier to wrap your entire RPC/API endpoint in a single db transaction than it is to issue multiple commits (e.g. an RPC to a microservice that writes) and worry about the large number of states that can result if your endpoint crashes mid-way.

[jamestenglish]

This was poorly worded on my part, Kubernetes does not in anyway solve this problem.

Instead I meant to use Kubernetes as an example of the work being done to standardize and abstract these sorts of microservice issues. Kubernetes solves a lot of orchestration issues and I expect there will be greater work with other projects into solving other problems like distributed transactions in the future.

The current thoughts on microservices is that you should really re-evaluate how critical strong transnational guarantees really are to your application.

[usaar333]

> The current thoughts on microservices is that you should really re-evaluate how critical strong transnational guarantees really are to your application.

Are there some examples of what else one can do?

I'm generally fine with service 2 eventually being called if service 1 is, but then I need that to happen.

e.g. I have a payment service and an internal "subscriptions service". If user requests a refund, I have to both issue refund to payment service and cancel internal subscription