[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.