[ryanobjc]

I'd tend to agree on a general sense - yeah when faced with failure in a WAN environment, it makes sense to attempt to continue when at all possible.

However, banks are one of the biggest purchasers of ACID systems... They still bet heavily on oracle, and when they want their accounting systems to run, and balance transactions, they dont rely on "BASE" systems. Banks are also heavily dependent on business cycle and batch processing. Daily batches are common in credit card processing (end of business day settlement for example), and also in general bank systems.

Also eventual consistency means different thing. Some systems have a "eventually inconsistent" property to them (eg: Cassandra/Dynamo), and I'm pretty sure banks would NOT be ok with that.

I respect Brewer, he is a smart guy, but he is extrapolating too much from a small fact that is ATMs will sometimes dispense cash (of what amounts? $200? $1000? or maybe just $20?) when remote communications are interrupted or broken.

[seanmcdirmid]

I don't think Brewer is stating an opinion, rather a fact. Nor is it very surprising. I'm sure banks have huge IT operations where parts rely on ACID or BASE depending on need. But any massive distributed system can't really expect ACID to work very well.

I'm pretty sure "eventual consistency" doesn't mean "eventual inconsistency" under any reasonable interpretation.

[ryanobjc]

I dont think anyone would claim a massively distributed system should be fully consistent or ACID.

As for the eventual inconsistency remark, this is from the original authors of Cassandra at Facebook. They did not extend the use of Cassandra because node flaps and packet losses caused nodes to be inconsistent and have old data. Bringing that data back up to date was very difficult, since the anti-entropy algorithms were too expensive to run frequently. They also found that the R=W=2 was too costly in terms of performance, and well you know the rest :-)

[standel]

Do you have the reference?