Nothing new here, really. Michael Stonebraker: Errors in Database Systems, Eventual Consistency, and the CAP Theorem. Stonebraker doesn’t like the CAP Theorem or eventual consistency. Who knew? Oh, wait. Here’s the really, really short version of the CAP theorem.

If your network breaks, and it will, then you can preserve A by letting the pieces continue independently (and resolve things later), or you can preserve C by shutting down the non-majority pieces.

The “and it will” part is also addressed James Hamilton. I’ve worked on systems with several redundant networks, and they were still subject to partitions. Mostly the reasons come down to something Stonebraker alludes to in the context of databases but which is also true of networks: programmers aren’t perfect. If a database programmer screws up, they can take down the most carefully designed database no matter what consistency model it uses (Stonebraker’s case 2). If a network programmer screws up, guess what? Same story, except now it’s your carefully designed network that fails instead. Given enough time and a large enough system, even rare failures become inevitable. If you have a network, it will fail. Unless you’re willing to promote router glitches into whole-system failures you only get to choose CP or AP. An important point here is that in a consumer-facing system a failure of consistency might be well tolerated but a failure of availability might be disastrous, while in a “back room” system the exact opposite is likely to be true. Whole-system failure might actually be a valid option for a back-room system that’s already protected by redundant switches etc. so that other failures are more likely anyway (and probably more severe). Stonebraker apparently sees these as the only relevant systems, and dismisses anything not fitting that model. I’m not going to say that they’re irrelevant (hi Kirby) but I will say that they’re uninteresting. Whether they’re more common or not, more important or not, they don’t shed much light on the CAP/EC debate – but that debate is central to a different set of systems which are increasingly common and increasingly important.

At least when the network programmer screws up, the database might be able to handle it via eventual consistency. Bradford Stephens points out in JH’s thread that application programmers might not be able to do much with that, but abstractions leak and errors bubble up (in some form or other) and if they bubble up to someone who can’t handle them then maybe you would have been better off promoting to whole-system failure in the first place. Eventual consistency and vector clocks and all the other stuff I discuss here are about giving those higher-level programmers a chance, giving them an option if they want it, not saying it’s the only possibility. Yes, systems based on such principles can have “weird” behavior even in the absence of failures. Don’t like that? Don’t use them. Stonebraker’s right that eventual consistency might represent a poor tradeoff in many cases, and it’s all about tradeoffs. Some people live in an AP world, and must pay attention to these issues. Others live in a CA or CP world, and can ignore them. All three groups can and should coexist amicably. “Your problems don’t matter” just isn’t very constructive, but it’s apparently all some people have to say.