IME the only sane way to do this is to a) redraw the transaction boundaries, aka. avoid it, or b) don't do it (see below), c) idempotency -- so you can just

IME the only sane way to do this is to a) redraw the transaction boundaries, aka. avoid it, or b) don't do it (see below), c) idempotency -- so you can just retry everything until you succeed. You can do distributed transactions, but it's a huge pain operationally. (b) is not always as far fetched as you might think. The vast majority of Real World (e.g. inventory, order fulfilment generally, etc.) systems are actually much more like Eventual Consistency in practice, so you don't gain anything by being transactional when your Source of Truth is a real world thing. Inventory is a great example. It doesn't matter if your DB says that an item is in stock if there simply isn't an item on the shelf when it comes time to fulfill an order for that item. Tracking such things is always imperfect and there already other systems overlaid which can handle the failure case, e.g. refund the order, place on backorder, have a CSR find a replacement item, etc. etc. (Of course you want reasonable approximate values for analytics, logistics, etc.)