Eric Brewer on Why Banks are BASE, Not ACID – Availability Is Revenue • Hacker News Board

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

#41

Post by dllthomas » Thu, May 02, 2013, 2:37 PM UTC

abalone wrote: post #28

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…

An offline mode might be ephemeral and unpredictable as a natural occurrence, but should be pretty easy to create...

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

#42

Post by gbaygon » Thu, May 02, 2013, 2:47 PM UTC

GFischer wrote: post #40

diroussel wrote: post #36

Earlier quoted context omitted.

Which in turn agrees with the point of the original article. ATMS use BASE not ACID as it's more profitable to be available.

Those humungous overdraft fees will definitely be profitable :) BTW I've been scammed out of money by ATMs before - money was withdrawn from my account but some system jammed and I didn't get the money - and the bank was awfully uncooperative. So far I've had more luck with the "money under the mattress" method than with banks - and I wasn't trapped in the "Corralito" or other bank-aided money-stealing schemes http:/…

I see that you are from Uruguay, where you in Argentina at Corralito's time? ITT Uruguay is more trustworthy in banking terms.

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

#43

Post by LanceH » Thu, May 02, 2013, 3:05 PM UTC

jacques_chester wrote: post #20

Joeri wrote: post #19

Earlier quoted context omitted.

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

Yes, each step is a transaction, but the whole is not consistent at any one moment. Availability was chosen over consistency all the way up.

We see this pattern all over the place. The primary example is any place that accepts checks as payment. Availability is immediate, but consistency is not necessarily there.

You see it with a business making a PO. Lots of places will still take credit cards which are only processed daily (ok, this is becoming rare where there is cell service.)

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

#44

Post by GFischer » Thu, May 02, 2013, 3:15 PM UTC

gbaygon wrote: post #42

GFischer wrote: post #40

Earlier quoted context omitted.

Those humungous overdraft fees will definitely be profitable :) BTW I've been scammed out of money by ATMs before - money was withdrawn from my account but some system jammed and I didn't get the money - and the bank was awfully uncooperative. So far I've had more luck with the "money under the mattress" method than with banks - and I wasn't trapped in the "Corralito" or other bank-aided money-stealing schemes http:/…

I see that you are from Uruguay, where you in Argentina at Corralito's time? ITT Uruguay is more trustworthy in banking terms.

Uruguay had a smaller Corralito (and I was just starting out at the time, so I had no money in the bank).

Ecuador and Brazil also had their own versions. In the Uruguayan version, they didn't forcibly exchange the money, but they froze all bank assets for 3 years (losing out on interest, investment opportunities, exchange rates, etc...).

Uruguay is more trustworthy (especially with foreign investment) but it's not above such things.

Currently there's a big scare due to the huge exchange rate disparity with Argentina - which has an "official" exchange rate and a "real" exchange rate which is almost double the official one, and makes Uruguay non-competitive.

Edit: you're from Argentina, that's obviously not news for you :)

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

#45

Post by snarfy » Thu, May 02, 2013, 3:18 PM UTC

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…

Pretty much all POS systems have the ability to work in offline mode. The vendor can set the offline transaction amount to whatever they want, including disabling it. Typically, it is set to $75. If you go to a convenience store and they say "the system is slow today.. but it works", now is your chance to get away with Source: I am a former software engineer for a credit card transaction system vendor.

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

#46

Post by jasomill » Thu, May 02, 2013, 6:54 PM UTC

As someone who's had to dispute NSF charges for reordered transactions, I question the author's claim that ATM operations commute. Specifically, assume a $0 beginning balance. Then "withdraw $20 then deposit $200" might yield an error, $0 cash, and a $200 balance where "deposit $200 then withdraw $20" would net $20 cash and a $180 balance.

Or, as in my disputed case, $20 cash and a $140 balance, because the deposited check hadn't actually cleared by close-of-business, so end-of-day processing assessed a $40 negative balance fee despite the fact that the deposit "eventually" cleared. The first manager I discussed this with had the audacity to claim it was my fault for not somehow recognizing that the portion of the deposited funds the ATM made available for immediate withdrawal by design were not, in fact, available for immediate withdrawal.

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

#47

Post by rbanffy » Thu, May 02, 2013, 7:25 PM UTC

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…

With any significantly complex architecture, there are many ways of being off-line. You may be unable to check a balance, but able to validate a PIN, or unable to make a transfer, yet perfectly capable of doing every other transaction. In that situation, if you can validate the PIN without being able to check the balance and you know this type of card is issued to clients with a certain overdraft limit, it's safe to clear the transaction and just tell the backend it happened when all remote functions are back online.

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

#48

Post by jacques_chester » Thu, May 02, 2013, 11:47 PM UTC

LanceH wrote: post #43

jacques_chester wrote: post #20

Earlier quoted context omitted.

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

Yes, each step is a transaction, but the whole is not consistent at any one moment. Availability was chosen over consistency all the way up. We see this pattern all over the place. The primary example is any place that accepts checks as payment. Availability is immediate, but consistency is not necessarily there. You see it with a business making a PO. Lots of places will still take credit cards which are only proces…

Yes. I'd restate my original argument but I'd seem more than usually repetitious :D

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

#49

Post by stephen » Fri, May 03, 2013, 2:28 AM UTC

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…

> Instead there is a protocol of credits and debits and a settlement process to work out the exceptions.

Exactly--the ecosystem as a whole is BASE, but the individual systems are ACID, and the "eventual consistency" aspect is implemented as first-class logic in applications/processes.

I think BASE is a good ecosystem-level principle, but when it gets into datastores, then each individual system doesn't know what it's true opinion of the world is, much less how it can effectively coordinate with other similarly potentially confused systems.