Hmm, wouldn’t things have ended up the same inconsistent state if you had it all built as a single service in the first place? E.g. you still can miss a failure

Hmm, wouldn’t things have ended up the same inconsistent state if you had it all built as a single service in the first place? E.g. you still can miss a failure condition on the insurance side and end up with a committed transaction? Why was the failure missed in your opinion? Was it because of the opaqueness of the services? If you go monolith, you’ll of course have the advantage of having one place that orchestrates everything, the place where you start the transaction and follow up with credit card / insurance / email. But if you are forced to deal with micro services you can roll a poor man’s transaction in the form of a state machine for the whole process backed in the db. Ui proxy receives click, credit card service authorizes money, insurance generates, credit card service settles transaction, email is sent. The good thing about this whole affair is that you can very clearly see where something fails and why, because failure is not a special case, but part of the normal operation of the service. Also gets you the whole split up into micro services thing where different teams can handle different services. Bad thing of course is its massively more complex, so most probably is not justified. Transactions are great, but when they rollback, they rollback everything. Now if you want to actually understand and track what went wrong, you need to log stuff somewhere else, which in itself can also fail.