I apologize. For some reason I thought you were attacking the viability of microservice architecture because you can't do database-level transactions across several backends. You were arguing that services will sometimes need to lock each other, and I agree with that.

In the Ticketmaster example, I would be able to get a Ticket resource assigned to me before paying for it. But the ticket would be "locked" (in the sense that I couldn't print the barcode) until the Payments service marked it as okay, which would indeed be an example of one service locking another's resource.

I thought you were claiming that the action needed to be performed in a single database transaction, but you don't need or want isolation here. You want the world to observe inconsistent state in this case (i.e. no one sees my seat as "available" while I'm fumbling around with my credit card number). In which case it's perfectly practical to implement transactionality at the application layer, between microservices, rather than at the database level. But that point was never in contention. I apologize.

Obvviously there's not a dogmatic preference for inconsistent state, just an acknowledgement that ACID properties are not necessarily needed as often as some people think they are.

Also, obviously, you have to be careful with your failure modes. Charging someone without delivering shouldn't happen often but you don't need to design your entire infrastructure around making it impossible, given that refunds (and simply not capturing the charge you authorized) are both relatively easy to do, even if you want to avoid doing them all the time.