5 ms·
Transactions in bank accounts are actually not realized through DB transactions. It's easily visible if you ever had a failing payment: the amount gets subtract
by blablabla123 6y ago
Transactions in bank accounts are actually not realized through DB transactions. It's easily visible if you ever had a failing payment: the amount gets subtracted but added again right away after that. They have pretty strong auditing requirements.
- nurettin 6y agoThis is the only comment worth a thing here. Unless mongodb causes irrevocable data loss, eventual consistency is easily mitigated using an accounting service. I have seen one of them at work. Transaction amount comes in, it is compared with initial value and the session is kept open until the quantity is fulfilled. If there is a timeout, secondary systems try to recover or alert. Recovery can even deduct overfills or complete fills.
- zo1 6y agoThis seems ridiculously complicated and unnecessary for something that should be as easy as having a proper RDMS that is ACID compliant. I guess now we have one additional reason why banking has stagnated for so long.
- nurettin 6y agoIt is complicated, but necessary. You will get to the ridiculous part once you realize that executing brokers don't care about your acid guarantees or whatever.
- zo1 6y agoThanks for the info - I didn't realize we were discussing distributed transactions with external brokers/banks.
- KptMarchewa 6y agoBanking is integrations with literally hundreds different external systems.
- DonHopkins 6y agoAre we discussing HSBC bankers or Silk Road LSD dealers?
- deleted 6y ago[deleted]
- nurettin 6y agoI suspect ACID doesn't help either of them.
- kilburn 6y agoJust in case you (or someone else) don't know why you are being downvoted, I'll give you a few reasons: - Banks have to put these double-checking and reporting systems in place because the law mandates them to. No amount of ACID compliance in your database is freeing you from that. - These requirements are not stupid either: assuming you had a perfect system with perfect ACID compliance and 0 bugs ever (which we all know is impossible), a random hardware failure (or cosmic ray) can flip a bit somewhere and you are screwed. - Your comment reads as extremely condescending, which is never good to get your point across. - Not only that, but you dismissed the work of some of the best people money can buy in two sentences with 0 rationale. Next time you think you know better than an entire extremely well funded industry, think again, and again, and again. If you are still convinced you know better, please open shop because if you are right you'll not just make yourself the next self-made billionaire, but also probably improve our lives in the process.
- matt_d_rat 6y agoThis comment gives me hope that there are at least some decent people on Hacker News. Every time I read an article here I am put off from participating further because the comments are usually filled with toxic spew from peacock fan boys Who think they know better. You have my up vote.
- brainless 6y agoWhat has "amount gets subtracted but added again right away after that" have to do that with DB transactions? 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?
- willcipriano 6y agoNot the OP but I think it's essentially a event driven system as opposed to real time. 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.
- bouncycastle 6y agoSure, it just means that the processing is done in a batch job at the end of the day. However, it doesn't mean that the batch jobs don't use a database. There's probably something like db2 on the mainframe, possibly even COBOL or RPG
- sohamsankaran 6y agoYep, it's pretty clear they use IBM db2 on z/OS internally for some applications. Here's an example job posting: https://webcache.googleusercontent.com/search?q=cache:Aqb9oUECiiYJ:https://intellijobs.ai/job/HSBCJava-DB2-Corporate-Functions-IT-vlNi7DLloFfOK915ijrK+&cd=4&hl=en&ct=clnk&gl=in https://webcache.googleusercontent.com/search?q=cache:Aqb9oU...
- kenniskrag 6y agoIt depends on the country and currency but there is the SWIFT system, which works like messaging. There is also the SIC and EuroSIC. For SWIFT system as a bank you have an account on the other bank and sends an instruction to decrease your amount and book it to a receiver. If there are more than one bank between them it gets routed but always "own decrease and other bank increase". Only the receiver bank books to the client. This system works because every bank has an account on other banks and you can build up some paths.