Two-phase commit deals with network failure, not change semantics. The message itself (whether "BALANCE=40" or "SUBTRACT 40") isn't something that matters to 2pc.
And you were wrong because your example is not a good example of something not needing 2 phase commit, it was in fact an example of a 2 phase commit. That over-drafting you mentioned, that is deferred reconciliation.
Also wiki: "two-phase commit protocol (2PC) is a type of atomic commitment protocol". That's different from deferred conflict resolution from event log.
Phase 1 ATM Request to withdraw funds secures a lock
Phase 2 Gets the all clear, writes the new balance to the ledger, distributes funds.
Anything trying to modify the ledger at that same time should be blocked for the short time it takes to process the transaction.
This is how these systems work.
The reconciliation is what happens when you can't do 2pc or when it fails.
Re it being a network protocol, no, its been around d since the dark ages.
https://link.springer.com/content/pdf/10.1007/s10619-008-702...
> Phase 1 ATM Request to withdraw funds secures a lock
> Phase 2 Gets the all clear, writes the new balance to the ledger, distributes funds.
> Anything trying to modify the ledger at that same time should be blocked for the short time it takes to process the transaction.
So you're saying 2PC is basically just "acquire a lock... do two things... release lock"?
Once you get into implementation detail you have to deal with a heap of failure modes which is what the article is complaining about in the premise.
What I don't really understand is how their solution isn't basically just sharding (in some form.)