You Can't Sacrifice Partition Tolerance (response to Stonebraker)

Stonebraker says real systems can obviously achieve "CA" when one node is partitioned off. But he slyly switched out the theorem's definition of "available" for a more colloquial definition. The CAP theorem definition requires every live node, including the lone segregated guy, to respond to clients. Real "CA" systems don't do that--they're "available" because the non-partitioned nodes are still responding.

did anyone else notice we have 3 posts a week about the cap theorem? Maybe it's about time we stop talking about it and start using some other terminology.

"Even the canonical example of an isolated transaction—a transfer of funds between bank accounts—happens with a 24-hour window of indeterminacy. In fact, one of the few financial transactions which actually resembles a database transaction is the physical exchange of cash for goods—a totally analog experience."<p>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.<p>My bank transfers between accounts happen instantly. Buying stuff online isn't an analog experience, and happens instantly.<p>Let's not put banking into the same category as a Twitter-like app, because they're nothing alike.<p>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.

<i>Every failed Google search means fewer ads served and advertisers charged</i><p>No, I just hit refresh a couple times or try again later. Same number of (successful) pageviews, same number of ad impressions.<p><i>every item a user can’t add to their shopping cart means fewer items sold</i><p>No, I try again later. Just like I do if something is out-of-stock.<p><i>every unprocessed credit charge risks a regulatory fine</i><p>So what just happened to that 24 hour window you mentioned for banking transactions?<p><i>The choice of availability over consistency is a business choice, not a technical one.</i><p>Right. Because it's safer for Citibank to approve a transaction that they shouldn't, than for them to process it five minutes late.<p><i>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><p>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.