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

21–30 of 49 posts

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

#21

Post by dllthomas »

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…

I think "if the system as a whole doesn't require ACID, maybe the pieces don't" is correct and useful, but it still requires looking at the pieces and seeing if that's the case. In this case, I think that the system is relying on the ACIDity of some components to ensure Eventual consistency - it's conceivable that an alternate method might not, but one would have to be proposed and evaluated.

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

#22

Post by jacques_chester »

dllthomas wrote: post #21
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…

I think "if the system as a whole doesn't require ACID, maybe the pieces don't" is correct and useful, but it still requires looking at the pieces and seeing if that's the case. In this case, I think that the system is relying on the ACIDity of some components to ensure Eventual consistency - it's conceivable that an alternate method might not, but one would have to be proposed and evaluated.

I think this is reasonable; but then the problem becomes that while consistency may be eventual there are nevertheless fixed deadlines to meet. Soft realtime consistency isn't good enough when the annual report has to be printed.

Personally, I feel that ACID is an abstraction achievable only within single, non-distributed systems. Not a very compelling insight, I hear you say.

Well no, but ACID is a tremendously advantageous state of affairs and I feel it should be surrendered only begrudgingly. I think it is better to repair it than to abandon it wholesale at the first sign of mild inconvenience.

Even though it is, in a physical sense, untrue, it is a useful untruth. Newtonian physics is wrong. It's also what we use to build bridges.

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

#23

Post by natermer »

felipesoc wrote: post #17
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 c…

Each bank is different. Some banks have shitty IT and other ones have dynamic IT that can adjust to fit changing realities.

The reality is that you and Eric are right.

Banks depend on techniques based on double book keeping accounting to reconcile accounts at end of day. Different data about transactions are stored in different places by different organizations and they compare books to make sure that balances are correct.

You cannot depend on every transaction to be recorded perfectly. You must have the ability to compare books and reconcile accounts. This is simply how the world works.

Trying to make every perfect and depending on storing data in a central place with the assumption that it's always going to be consistent is too much of a liability. It doesn't work because the systems required by modern financial systems are incredibly complex and availability during markets is the highest priority. You ARE going to have faults and you ARE going to have problems. The ability to take hits gracefully and give yourself time later on to fix stuff after the fact must be built into your systems.

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

#24

Post by dasil003 »

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…

I think you're missing the forest for the trees here. The point of the article is not the specific semantics of ATMs, but rather the whole system of banking and how it accounts for CAP theorem.

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

#25

Post by biggfoot »

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…

... and why would they do that?

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

#26

Post by dasil003 »

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…

Well given that his thesis is that banking has always worked this way, and since banking is older than computers, I don't think there was any implication here that it was an engineering choice.

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

#27

Post by rjempson »

This is an example of why analogies should never be used (except perhaps if trying to explain a concept, not something tangible).

ATM software has nothing to do with the backend storage of the data. My point is that I bet when the data is actually written to durable storage in the backend, the set of data being written will be wrapped in an ACID transaction.

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

#28

Post by abalone »

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…

That's smart, but what he's saying is plausible. First of all significant parts of the world use chip-and-pin cards that can authenticate the pin locally. Not that they are hack proof by any means, but considerably better than mere magnetic strips like we still have here in the US. Moreover, if the offline mode is ephemeral and unpredictable, then it's less prone to exploitation. Again, not immune and not the safest thing for an ATM vendor to support, but the overall fraud risk could conceivably be within their comfort zone.

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

#29

Post by timv »

Maxious wrote: post #15
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…

Leaving aside the fact that I wouldn't trust a newspaper to for the technical details of something like this, nothing in the article contradicts what jeremyjh said.

In that case, the ATM was disconnected from the accounting system and allowed withdrawals up to a set limit ($2000), but it (probably, the article is unclear) was still connected to the authorization system.

It (probably) still checked your PIN, and checked whether your card had been cancelled, etc. It just didn't connect through to check your balance.

As Jeremy said if for some reason we can't reach the checking account system we'll authorize up to $xxx total for the day on a stand-in basis

In this case some reason == "[A technical problem]" and xxx == $2000

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

#30

Post by PeterisP »

stephen wrote: post #6

A nit, but the remark of "auditing == everything is written down twice == double-entry accounting" is cute, but doesn't seem applicable to availability. Double-entry is more of an internal (financial) system implementation detail, and so an orthogonal concern to intra-system audits. (It's not like one side of the entry is in one bank's IT system, and the other side of the entry is in the other bank's IT system.) (...…

Funny, but "It's not like one side of the entry is in one bank's IT system, and the other side of the entry is in the other bank's IT system." is actually false in interbank deals such as correspondent accounts, money market or forex deals.

If a deal involves two banks, then the authoritative "other side" of the entry will be in the other bank's IT system. Of course, you'll maintain some records of what the entry should be in your opinion, but they won't always match as you don't have full info and you'll reconcile with data you get from the other bank's IT system by (for example) SWIFT network.

And I've seen only double-entry OLTP's for the core system that includes general ledger. Maybe no all of them are built that way, but I haven't seen such examples.

Post reply on HN