[mrkeen]

Even though ACID-compliant databases are very trustworthy, it's still bad practice to mutate amounts of money in-place, even if you trust the database not to duplicate or destroy money. "Accountants shouldn't use erasers" and all that.

If you're dealing with money, you should at a minimum have some kind of ledger, and derive the current state from that.

Calling an SQL transaction "Classic funds transfer" is a bit of a disservice to all the banking that happened before databases. Mesopotamians were recording transactions on clay tablets 5000 years ago.

[numbsafari]

Thank you.

Using incorrect and invalid models of real world systems and using them as exemplars of technical concepts, even as a short hand, is a sign of a not well written document.

It gets worse, because the "level up" to distributed transactions builds on the model by trying to show two banks engaged in a distributed transaction using 2PC to handle a funds transfer. This doesn't exist. It's not a thing. It never has been. There's nothing "classical" about this example.

It exists in the same canon as "a manager is a person. an employee is a person..." examples to explain data modeling.

Using these "examples" leads readers (learners) to walk away with incorrect understanding that they will likely spend a ton of time having to unlearn and overcome.

[hinkley]

I've been job hunting lately and one of the positions was for someone trying to disrupt Visa. It took me years of chats with billing folks and dealing with declined purchases to piece together what I know about how credit cards actually work, and it's just the tip of the iceberg.

Good luck with your Chesterton's Fence adventure boys. You're gonna need it.