That's often not practical. Say you're a shop front.

If you have a goods purchase service and a goods delivery service, you want to reserve the good (limited quantity) and reserve a time slot for transport (limited number of deliveries a day) before you charge the customer, and make the "commit".

And if you'd merge two separate companies into one uber-service, you've just created more problems than you've solved.

> "In practice, it makes much more sense to allow the system to enter certain inconsistent states and then remediate them. Out of an ingredient? Refund the money. Can't pay? Pull the drink out of the queue, or just write it off. This can involve some cost, but less cost than than the throughput you'd lose by enforcing consistency."

I don't know what practice you're referring to, but unlike commodity coffee drinks paid for in cash 1) CC refunds are not free, and they're not cheap in volume at all if you intend to do it casually during normal operation 2) not all goods are standardized and available in large quantities.

Your examples are all over the place. Ticketmaster is an example of a reservation system similar to one I was trying to give an example of (two step commit). A resource is locked, the lock is held for a short period while collecting answers from the other subsystems (in this case, payment gateway), and then a final commit is issued (or a rollback is issued).

Airline overselling isn't done because it was some microservice design dogma about how great inconsistent state is, but because every seat costs the airline a fortune if left empty, and a certain % of passengers cancel or reschedule their tickets, and the airline is trying to arrive at an airplane with as few empty seats as possible. Having your tickets canceled is certainly not something that happens "often", thank god, but it does happen as a result of that tradeoff.

But if I reserve and buy my seats online for a cinema movie, and then I go with company and get handed my money back because "it's practical", I'll make a scene. And so no one implements cinema ticket reservation this way.

For bank overdrafting, it's a very special case - your money is a number in a computer, and the bank owns that computer. They make the rules... so they did. It's easy to mess around with numbers like that. Bank account overdrafting is probably the biggest exception of them all as no physical products and services are involved. No one's going to have their lawn un-mowed because the bank allowed your account to overdraft.

The only common thing between your examples is that they're driven by business concerns, not some ivory tower concern about service design. And this is why they're so different, and reserving resources is and will remain a common practice for many, as long as the business logic calls for it. There's nothing wrong about it.

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.

Well, as usual most arguments revolve around misunderstanding terms, and not substance, heh. I was too harsh in few places, as well. Sorry.

I really don't feel there's a need for us to separate "native" database transactions and app-level transactions. They're both implemented using the same underlying principles. But I've noticed people see a huge difference between them in blog posts, articles and conversations.

I think it reveals a kind of thinking that database transactions look like magic, while those we roll ourselves... we see all the ugly parts of the sausage factory there, and it no longer feels as "atomic" or magical as what databases expose as an encapsulated abstraction.