You Can't Sacrifice Partition Tolerance (response to Stonebraker)
codahale.com
codahale.com
It also models nuked (hardware failure, power outage, whatever) nodes as being in an isolated single-node partition. Which becomes rather interesting in combination with that definition of availability.
This sounds like a fencepost type of error to me. When you have a partition, you are splitting a single set into two subsets. It may be live/dead or live-net1/live-net2. The point is, in the presence of a partition, there are no non-partitioned nodes.
With all due respect, that's a bunch of bullshit, and is a great example of passing off how you think something works as how it does work.
My bank transfers between accounts happen instantly. Buying stuff online isn't an analog experience, and happens instantly.
Let's not put banking into the same category as a Twitter-like app, because they're nothing alike.
It's perfectly okay that two different solutions exist for two different sets of problems, and there's no real need to argue that your world view applies to all problems.
As for credit and debit charges, my bank always has two transaction histories. Cleared transactions and pending transactions. Pending transactions are merely funds that have been reserved against your account and they may or may not clear after a period of time. Sounds like that fits pretty well with eventual consistency.
My bank transfers to other banks take a couple of hours, but I don't live in the US. The money comes out of the account instantly though.
I think it's a bit of a stretch to say that a bank doesn't need transactions.
As for credit cards, that's great, but that doesn't address what he said, which is that it's an analog experience, which it isn't. Also, it depends on the bank, but there's generally an available balance and a credit limit. Credit card payments come out of the available balance instantly. I'm pretty sure that's running in a transaction. :)
What happens between then and actual acquisition is irrelevant.
Anyway, the point isn't the technical details, or how implementations differ. The point is that the argument presented is flat out wrong (in this case). Banks are a completely different beast to your web 2.0 startup. :)
What happens between the time the money is debited from one account and it shows up in the other? Hint: it's not a transaction in the ACID sense of the term.
I would address the rest of what you say, but I'm afraid I cannot help you on your reading comprehension. I encourage you to read the article. All the words please.
Within a single banking entity (and what you see as your bank might in fact be a composite of numerous such entities), you may see this _apparently_ transactional behavior. Between banking entities you certainly don't. There is no 2PC over SWIFT.
Crushed your dreams. Sorry.
No, I just hit refresh a couple times or try again later. Same number of (successful) pageviews, same number of ad impressions.
every item a user can’t add to their shopping cart means fewer items sold
No, I try again later. Just like I do if something is out-of-stock.
every unprocessed credit charge risks a regulatory fine
So what just happened to that 24 hour window you mentioned for banking transactions?
The choice of availability over consistency is a business choice, not a technical one.
Right. Because it's safer for Citibank to approve a transaction that they shouldn't, than for them to process it five minutes late.
Given this economic context, it becomes clear why most practitioners at any interesting scale meet their business needs using highly-available, eventually consistent systems.
I thought it was because consistency usually costs a bit of performance, and at "interesting scale" that translates into significant hardware costs. Plus of course "interesting scale" apparently comes with "rockstar programmers", who prefer eventual consistency because it's a fun exercise in minimalism.