Response to Alex Popescu on "The demise of eventual consistency"
This weekend GigaOM published a piece called "Next gen NoSQL: The demise of eventual consistency?" by my co-founder Dave Rosenthal. Generally, the response was positive and many people (including Alex Popescu) said it was well written. However, on his blog Alex had some criticisms of the article. Here, I'll respond to them.
Alex: What I cannot agree with though, are weak statements like (what does unreliable writes mean?) :
Eventual consistency pushes the pain and confusion of inconsistent reads and unreliable writes onto software developers.
I can't speak for Dave here, but I think he's trying to summarize a very complex concept for an audience that isn't expert in the field of database technology. In an eventually consistent database system, a write could be made by one client, but not seen by another client looking up the same information. Characterizing this write as "unreliable" for the general audience of GigaOM seems fair.
Alex: And definitely I cannot agree with unproved statements used solely to prove your point:
A system that keeps some, but not all, of its nodes able to read and write during a partition is not available in the CAP sense but is still available in the sense that clients can talk to the nodes that are still connected. In this way fault-tolerant databases with no single point of failure can be built without resorting to eventual consistency
By changing the definitions, you are not proving a theorem is incorrect. Nor do you prove a different theorem.
What is unproven about this statement? Nowhere are we attempting to imply that the CAP theorem is incorrect. We're simply clarifying that "Availability" in the CAP sense doesn't mean what it seems to mean to most people the first time they hear it.
This is a very real misunderstanding. Example - if you asked most people the question:
"If a database is designed so that it doesn't remain available during a network partition, can it serve read or write requests to clients during a network partition?"
they would say "No". However, that would be an incorrect answer for CP systems like FoundationDB which can remain "available" (in the common understanding of the word) to serve traffic to clients in many network partition cases, while not being "Available" in the CAP sense because disconnected minority partition nodes are unable to serve requests.
This may seem obvious to someone who has deep knowledge of distributed databases, but this is a very common misconception that we encounter all the time, and leads many people to believe that systems like FoundationDB cannot exist. They can. We built one.
Don't believe us? Watch 4:38 of the FoundationDB fault tolerance demo video where Dave shows a FoundationDB cluster continuing to serve client requests during a network partition.
Still don't believe us? Download it and test it for yourself.