[gav]

When it comes to this topic, almost all examples don't match how things work in the real world where they are eventually consistent.

For example, my bank lets me go negative and then if I don't settle by the end of the day, overdraft protection will kick in for a little more than that negative amount.

[jen20]

Indeed - seeing account balance used as an example of database transactions is a red flag to me, and would absolutely cause me to dig deeper into whether the author/speaker understands how banking actually works.

[amw-zero]

Hello, I wrote the post.

I don’t claim to be a banking expert, but I did work at a payment processor that handled real money, and we used “select for update” extensively.

We also (obviously) used a ledger, but “just let everyone overdraft whenever” wasn’t something that the executives of the company thought was a good idea. So we did try and prevent insufficient funds errors as much as possible.

I personally witnessed several scenarios where the company lost a notable amount of money, (not only rated to concurrency bugs of course) and it’s a pretty bad feeling.

Anyway, I’m legitimately curious to know from people who worked at larger banks perhaps. How is weak transaction isolation not a problem for banks?

[amw-zero]

Can you elaborate? Does your bank allow you to overdraft on $50k for example? I think it’s more complicated than “eventual consistency solves all problems.”

[gav]

I assume there's some point where they will start declining transactions and it could be some fixed number or some complex calculation based on all the data the bank has about my finances.

My point is that these examples are bad ones because they don't match the real world, which is messy and complex and inconsistent.

[amw-zero]

I hear what you're saying, the real world is often complex. However, I don't agree that means banking examples aren't useful, because they do lay out the problem that all banks have to consider, one way or another.

There are many ways of solving the consistency problem, but understanding what consistency and serializability is means that you'll be better educated in coming up with solutions.

Also, I believe that all else being equal, you would want serializability. It simplifies everything. There's a new [financial database under development named TigerBeetle](https://docs.tigerbeetle.com/design/consistency). They chose to implement strict serializability by default because:

> Strict consistency guarantees (at the database level) simplify 1) application logic and 2) error handling farther up the stack.

So the banks of today may have to deal with inconsistency, but that doesn't mean the banks of tomorrow want to.