Hacker News Reader

Comment by hcarvalhoalves | Hacker News Reader

> The canonical example of a transaction is transferring money between bank accounts: to transfer $100 from me to you, the bank runs a transaction which withdraws $100 from my account and deposits $100 in your account. By running both operations in one transaction …

I know it’s canon at this point, but please stop using this example people. No bank ever worked this way, and often outsiders who hear about this example get the wrong idea.

View on HN

Here's the example I point people to when talking about transactions: https://sakurity.com/blog/2015/05/21/starbucks.html

I'm curious -- how do banks actually do this, then?

Ledgers. They record a list of transactions, they don't just plus or minus the balance.

But to record a transfer with a list of transactions, you need at least two transactions, and you need to write both transactions atomically in the ledger. Otherwise you end up with the same problem.

https://en.wikipedia.org/wiki/Double-entry_bookkeeping

This is a checksum-like trick for manual record keeping, and isn't specifically relevant to the grandparent. It isn't required in digital world. The grandparent talks about having to write 2 separate transactions in 2 accounts in such a way that either both are successfully written, or none are written. This means that there must be transactionality between 2 services, regardless of balance being cached or not.

The point is that there is no such thing as "2 separate transactions in 2 accounts" in banking. There is one global ledger that contains transaction between all accounts - if you move money from account A to account B, you append one entry to the ledger that says that some sum of money moved from A to B. Then if you need to calculate an account balance, you look at all transactions in the ledger, filter by the account ID, and calculate the total. (You can then cache this result, for performance benefits, but this changes nothing about the way it works.)

This is really more like a CRDT than like transaction control.

It's also where Bitcoin took its inspiration from, the blockchain is just one big ledger with some hashing on top.

This is a good explanation for Bitcoin-type ledger, but as far as I understand, banks don't share a global ledger. In US they run settlements through FED, which is the closest thing to global ledger we got, but internally they keep their own separate ledgers. Fed sees settlements between banks, but allocation within a bank is done via internal transactions. If you wanted to give banks a transfer rail that allows them to communicate directly incurring liability, and later settle via FED, you would need to write a transaction in each bank's ledger.

Bingo

Eventual consistency is a thing.

Or, are you old enough to have learned to reconcile a checkbook? Where you keep track of all the checks you write and what your balance should be, and then mark them as confirmed when they show up on your (monthly, because paper via usps) bank statements?

Or you can throw both transactions into an event queue and let the worker process each whenever it gets to it. You get the point...

Then the source account could not have the funds for the transaction at the time the operation is ... transacted

Which regularly happens with bank accounts - hence overdrafts.

The truth is, this does happen, but you want it to happen less. Banks accept certain amount of risk due to logistical limitations, but always seek ways to reduce it.

Tradeoff between availability and consistency. Not to error when accepting a transaction probably makes bank good money, but showing correct numbers all the time or handling transactions larger than entire account balance probably only ever helps poor people like me who anxiously check incoming transactions at the ATM and we don't make banks lots of money. So a queue of transactions to record doesn't sound like a problem, but idk I don't work at a bank

Overdrafts come with limits--hence the need for a transaction to check that we are within the limit.

I don't use credit, zero overdraft, saw it go negative many times.

Accounts go over their overdraft limits all the time. Arranged overdrafts are simply the limit the bank promise to honour without punitive fees, not an absolute limit.

Honestly I have seen enough times purely savings/debit account goes negative a few dollars that what you describe is probably not a show-stopper :) Only if discrepancy is large enough then probably transaction gets flagged and a human steps in.

Or the queue could be strongly ordered.

You only need one single transaction. The value of each account is deduced from the list of transactions that happened with checkpoints (fancy caching) once in a while.

I believe the modern term is "event sourcing".

And the events include things like "refused because the destination account has ceased to exist", "refused because the currency is invalid", "refused because the amount has too many decimal digits", "refused because we are boycotting you", and so on. Anything can happen.

But usually they also store current balances in a separate table, and updating them is also part of the transaction.

Float, overdraft, clearing houses.... are all examples of solving the "transaction" problem with eventual consistency.

What's an intuitive example which should be used instead?

I will keep using this example. It's a good example for illustrating why transactions are necessary and what they are. And it's not relevant whether or not banks actually work this way.

The counterargument is that it's not a situation where transactions are actually used so it's not a good example for why transactions are necessary.

Reply on news.ycombinator.com