[jacques_chester]

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

[dllthomas]

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.

[jacques_chester]

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.

[Joeri]

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.

[jacques_chester]

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

[LanceH]

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

[jacques_chester]

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