Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eric Brewer on Why Banks are BASE, Not ACID – Availability Is Revenue

highscalability.com

Post reply on HN
Print view View original

11–20 of 49 posts

Re: Eric Brewer on Why Banks are BASE, Not ACID – Availability Is Revenue

#11

Post by artsrc »

Aloisius wrote: post #9

Citation needed. I've never heard of financial systems being eventually consistent, certain not ATMs which need to know your exact balance and how much money you've taken out already today.

http://www.abc.net.au/news/2011-03-01/cash-spews-out-of-comm...

I studied ATM's at Uni, and they have been like that for over 26 years.

As someone else on the thread pointed out, they do authenticate you, and record the transaction in a aci(Durable!) database before they give you money. But the system clearly has a degraded mode when the exact balance is unavailable.

Also why do you need a balance to process a deposit?

Re: Eric Brewer on Why Banks are BASE, Not ACID – Availability Is Revenue

#12

Post by exabrial »

Sorry, but Eric Brewer is wrong. He seems to be implying that there was some sort of intelligent design behind the software at banks that lead them to choose BASE. This couldn't be further from the truth.

Banks are one software kludge after another in attempt to not rewrite something new or offer the consumer anything of value... while paying out the butthole to whatever vendor has his arm shoved so far up your ass you can't ever migrate from their platform without colon replacement surgery.

So while it's a nice thought "Hey look Banks/ATMs are BASE" this was by complete accident through years of incompetence and corporate bureaucracy, not by any sort of engineering choice.

Re: Eric Brewer on Why Banks are BASE, Not ACID – Availability Is Revenue

#13

Post by SoftwareMaven »

jeremyjh wrote: post #7

>If an ATM is disconnected from the network and when the partition eventually heals, the ATM sends sends a list of operations to the bank and the end balance will still be correct. I don't think so. I support ATM client software for a large bank in the US and we certainly don't do this. This may be true for "remote" ATMs that are installed in convenience stores on POTS. I can't say I've ever actually heard of it thou…

Reading this, it doesn't sound like you said anything different. Sure, it isn't the ATM itself that makes the decision, but the authorization system can still step in and allow a transaction that is not committed to the actual account's log.

I'm sure that, under the hood, there are a lot of ACIDic transactions going on, but, stepping back, it still looks pretty BASEic. When I hit "withdraw $200", there is no guarantee that my actual account has a transaction commit for that amount. Instead, there may just be a log message saying "SoftwareMaven withdrew $200".

Re: Eric Brewer on Why Banks are BASE, Not ACID – Availability Is Revenue

#14

Post by SoftwareMaven »

jacques_chester wrote: post #10

This is one of those cases where deciding on whether the system is ACID or not depends entirely on where you draw the system boundaries. If you draw it at the boundary of the central general ledger, it's going to be ACID. If you look at the way transactions pass through several intermediate systems (each of which is ACID) en route, I guess it could be called BASE.

I think the point is that people who say it is impossible to build a banking system without full transaction support for every action are ignoring the reality that transactions are not guaranteed to occur, but the actions themselves are. If, at a level of abstraction, the system can be said to be a BASE, then it is probably true that the underlying data stores are not required to be ACIDic. Whereas everything I've read has always said "you can't do banking without ACID".

Whether that is true or not is a much deeper discussion that three or four paragraphs on a blog.

Re: Eric Brewer on Why Banks are BASE, Not ACID – Availability Is Revenue

#15

Post by Maxious »

jeremyjh wrote: post #7

>If an ATM is disconnected from the network and when the partition eventually heals, the ATM sends sends a list of operations to the bank and the end balance will still be correct. I don't think so. I support ATM client software for a large bank in the US and we certainly don't do this. This may be true for "remote" ATMs that are installed in convenience stores on POTS. I can't say I've ever actually heard of it thou…

> just spewing out money to every piece of plastic calling itself a card when your network connection has been dropped isn't really a recipe for success.

Well they do this in Australia... http://www.news.com.au/money/banking/computer-glitch-hits-cb...

> "People were running past me screaming 'Free money! Free money!'," Punchbowl Pharmacy manager Feriale Zakhia said of the people using a nearby ATM.

> "Everyone was so happy. They were running around with huge smiles."

> [A technical problem] forced the bank to put all of their ATM machines into offline mode. Customers had no access to their account balance but were still able to withdraw money - more than their accounts held.

> Those withdrawal limits are up to $2000 a day for holders of keycards and debit Mastercards.

> "No one has received free cash," Mr Fitzgerald said. "What they've done is overdrawn their accounts. We will be following those people up and recovering that money."

Re: Eric Brewer on Why Banks are BASE, Not ACID – Availability Is Revenue

#16

Post by jacques_chester »

SoftwareMaven wrote: post #14
jacques_chester wrote: post #10

This is one of those cases where deciding on whether the system is ACID or not depends entirely on where you draw the system boundaries. If you draw it at the boundary of the central general ledger, it's going to be ACID. If you look at the way transactions pass through several intermediate systems (each of which is ACID) en route, I guess it could be called BASE.

I think the point is that people who say it is impossible to build a banking system without full transaction support for every action are ignoring the reality that transactions are not guaranteed to occur, but the actions themselves are. If, at a level of abstraction, the system can be said to be a BASE, then it is probably true that the underlying data stores are not required to be ACIDic. Whereas everything I've re…

> If, at a level of abstraction, the system can be said to be a BASE, then it is probably true that the underlying data stores are not required to be ACIDic.

I don't think this follows. While the system as a whole might be eventually consistent (where consistency is defined as: what's in the General Ledger), it doesn't follow that you relax constraints on the parts.

The individual components are generally ACID and the steps to move data are ACID as well. The only thing that prevents the whole system from being ACID is that transactions don't go immediately from POS/ATMs/card clearance/cheque clearance into the General Ledger, but instead must go through a series of intermediate transactions. But those intermediate transactions must, themselves, be ACID.

That's why I talked about how the boundaries matter. The final central accounts are ACID, the subsystems are ACID and the data transfers are ACID.

edit: though to contradict myself, I expect that there will be counterexamples in different banks where some stores or steps will not be strictly ACID, but will have been "good enough" or with sufficiently-acceptable workarounds that they haven't been upgraded. I don't think this fatally breaks my argument, but YMMV.

Re: Eric Brewer on Why Banks are BASE, Not ACID – Availability Is Revenue

#17

Post by felipesoc »

exabrial wrote: post #12

Sorry, but Eric Brewer is wrong. He seems to be implying that there was some sort of intelligent design behind the software at banks that lead them to choose BASE. This couldn't be further from the truth. Banks are one software kludge after another in attempt to not rewrite something new or offer the consumer anything of value... while paying out the butthole to whatever vendor has his arm shoved so far up your ass y…

That's not true. I've worked for a company that makes banking software and we did tons of migrations. The company itself changed its own software from RPG in as400 to windows forms and now it's all web with servers in Java and .Net (they use a middleware language which generates in every new platform). They even made a transitional install for one branch of one of the most important banks. The branch used my former company's solution for a few years until they could use their own software, which had to be adapted for the new market.

Banks used to work on paper an did fine, software migration, although can take some years, is no problem for them.

Re: Eric Brewer on Why Banks are BASE, Not ACID – Availability Is Revenue

#19

Post by Joeri »

jacques_chester wrote: post #16
SoftwareMaven wrote: post #14

Earlier quoted context omitted.

I think the point is that people who say it is impossible to build a banking system without full transaction support for every action are ignoring the reality that transactions are not guaranteed to occur, but the actions themselves are. If, at a level of abstraction, the system can be said to be a BASE, then it is probably true that the underlying data stores are not required to be ACIDic. Whereas everything I've re…

> If, at a level of abstraction, the system can be said to be a BASE, then it is probably true that the underlying data stores are not required to be ACIDic. I don't think this follows. While the system as a whole might be eventually consistent (where consistency is defined as: what's in the General Ledger), it doesn't follow that you relax constraints on the parts. The individual components are generally ACID and th…

If you pick sbsets of the transaction, then cassandra is ACID in part because it guarantees that a write leaves an entry in a node's log. A banking system only guarantees a log of all increments and decrements, not agreement of the current balance throughout the system. So, as a whole, the system is definitely BASE and not ACID.

Re: Eric Brewer on Why Banks are BASE, Not ACID – Availability Is Revenue

#20

Post by jacques_chester »

Joeri wrote: post #19
jacques_chester wrote: post #16

Earlier quoted context omitted.

> If, at a level of abstraction, the system can be said to be a BASE, then it is probably true that the underlying data stores are not required to be ACIDic. I don't think this follows. While the system as a whole might be eventually consistent (where consistency is defined as: what's in the General Ledger), it doesn't follow that you relax constraints on the parts. The individual components are generally ACID and th…

If you pick sbsets of the transaction, then cassandra is ACID in part because it guarantees that a write leaves an entry in a node's log. A banking system only guarantees a log of all increments and decrements, not agreement of the current balance throughout the system. So, as a whole, the system is definitely BASE and not ACID.

So we're back to a boundary argument, again. Partisans will draw the boundaries as it suits their argument.

Though, I do need to emphasise a point:

> subsets of the transaction

Each step in moving the information from the ATM to the General Ledger is itself a transaction. There are no "subsets of a transaction". If it's divisible, then it's not a transaction (this is the atomicity requirement of ACID).

Post reply on HN