Basically each Banking transaction is an immutable log, which can easily reside in a DB with DB transactions feature. They are not related.
Can you please elaborate in technical terms what you mean?
Basically each Banking transaction is an immutable log, which can easily reside in a DB with DB transactions feature. They are not related.
Can you please elaborate in technical terms what you mean?
Think of a account with $0 in it.
1. A -$25 event comes in
2. A +$50 event comes in
3. A -$25 event comes in
The first event would fail in a transactional/real time system, but in my bank it doesn't. This tells me the balance is only calculated every once in a while. The balance you get in a app is only a estimate.
This makes sense when you think how slow bank transfers and using paper checks is. At some point it is decided to run the events "for real" and that's where overdrafts and the like are applied.
Don't think of them as transactions, instead it's a transaction request that can be rejected.
In your example, a “good” bank would order the transactions: +$50, -$25, -$25 resulting in a zero balance with no penalties. What Wells Fargo did could result in the transactions being ordered as: -$25 (overdraft), -$25 (overdraft), +$50.
Each overdraft could charge a fee up to $35, leaving the account holder with a -$70 balance.
[1] https://www.latimes.com/nation/la-fi-court-bank-overdraft-fe...
Additionally, the number of folks that ask for spreadsheets (not encrypted) with your SSN... and then proceed to email that data around (sometimes via Gmail!)
1. Client initiates the transfer request.
2. Bank A decreases the client's balance.
3. Bank A sends the request to transfer money to bank B.
Now, I guess you would expect that steps 2 and 3 should form part of a DB transaction. This however does not really work because it is unclear what conclusion we should draw from step 3 failing. On one hand, it is possible that the request failed on its way to bank B, in which case step 2 should not be applied. On the other hand, it is possible that the request successfully reached bank B but the response got lost on its way back. In this case step 2 should be applied.
Therefore, not treating steps 2 and 3 as a single transaction makes sense if you want to take a conservative approach that does not allow for accidental transfer of infinite amounts of money to bank B in scenarios when the response fails to come back from an otherwise successful transfer.